| 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: | Whole Thread | Raw Message | 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 |