Re: XMLDocument (SQL/XML X030) - Mailing list pgsql-hackers

From Robert Treat
Subject Re: XMLDocument (SQL/XML X030)
Date
Msg-id CABV9wwMCN9FaprXhbP5ivkvKCuhBOiVTsOf7Ne6M566QXMRpzg@mail.gmail.com
Whole thread Raw
In response to XMLDocument (SQL/XML X030)  (Jim Jones <jim.jones@uni-muenster.de>)
Responses Re: XMLDocument (SQL/XML X030)
List pgsql-hackers
On Tue, Jan 21, 2025 at 5:58 AM Jim Jones <jim.jones@uni-muenster.de> wrote:
> On 20.01.25 23:21, Chapman Flack wrote:
> > Therefore I'm thinking that, given the specifics of our XML support,
> > a fully conformant and efficient XMLDOCUMENT could be implemented
> > just by returning its XML argument.
>
>
> After your explanation, I tend to agree.
>
> v3, attached, incorporates these changes and updates the regression
> tests accordingly.
>
>
> >
> > That opens a question of whether it's worth the effort to supply
> > it at all. Maybe it could reduce the surprise for people coming from
> > another DBMS and finding it missing, and/or be a placeholder in case
> > we ever implement enough more of the newer SQL/XML standard for it
> > to have a real effect.
>
> Although quite trivial, I believe this function could still be valuable
> in facilitating the migration of scripts from other database systems --
> improving SQL/XML conformance also isn't a bad thing :).
>

Is there some concrete use case you have seen that this would help
with? Not objecting to adding it, but you've mentioned this migration
idea twice but it seems to me this doesn't conform with existing
implementations, and I don't see much benefit in migration use cases
specifically, so I'm just curious if I am overlooking something?


Robert Treat
https://xzilla.net



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: attndims, typndims still not enforced, but make the value within a sane threshold
Next
From: Melih Mutlu
Date:
Subject: Re: speedup COPY TO for partitioned table.