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
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 |