Re: XMLDocument (SQL/XML X030)

From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
To: Robert Treat <rob(at)xzilla(dot)net>
Cc: Chapman Flack <jcflack(at)acm(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: XMLDocument (SQL/XML X030)
Date: 2025-01-21 23:35:56
Message-ID: 1dd6b4d7-aa29-402c-8e68-8ccd4f7f06bb@uni-muenster.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 21.01.25 23:45, Robert Treat wrote:
> 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?

I wouldn’t frame it as a "migration idea". My point is that this would
be one less function to modify when migrating a script from another
database system to PostgreSQL.

For example, in DB2:

SELECT xmldocument(xmlforest(10 as x, 20 as y)) FROM SYSIBM.SYSDUMMY1;

----------------------------------------------------------
<X>10</X><Y>20</Y>

  1 record(s) selected.

 ... This same query wouldn’t work in PostgreSQL, but the function makes
the query more compatible.

SELECT xmldocument(xmlforest(10 as x, 20 as y));

    xmldocument     
--------------------
 <x>10</x><y>20</y>
(1 row)

Which compatibility issues with existing implementations are you
referring to?

Thanks!

Jim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-01-22 00:14:22 Re: Show WAL write and fsync stats in pg_stat_io
Previous Message Tom Lane 2025-01-21 23:19:51 Re: allow trigger to get updated columns