Loose ends in PG XML patch - Mailing list pgsql-hackers

From Tom Lane
Subject Loose ends in PG XML patch
Date
Msg-id 23831.1166924699@sss.pgh.pa.us
Whole thread Raw
Responses Re: Loose ends in PG XML patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Loose ends in PG XML patch  (Peter Eisentraut <peter_e@gmx.net>)
Re: Loose ends in PG XML patch  ("Christopher Kings-Lynne" <chris@kkl.com.au>)
List pgsql-hackers
I cleaned up some things I didn't like in the recent XML patch, but
there are several loose ends that I lack the energy to tackle now:

* Isn't mapping XMLSERIALIZE to a cast completely wrong?  Aside from
the issue already noted in the code that it won't reverse-list
correctly, this loses the DOCUMENT-vs-CONTENT flag, which I suppose
must be important.

* Shouldn't the xml type support binary I/O?  Right now it is the only
standard datatype that doesn't.  I have no idea whether there is an
appropriate representation besides text, but if not we could define the
binary representation to be the same as text.

* Reverse-listing of XMLELEMENT and XMLPI is currently wrong because
the name string is not "de-escaped" back to a plain SQL identifier.

* It doesn't look to me like any thought has been given to localization
in xml_ereport() --- there are a ton of strings there that won't get
translated.

* I'm also quite afraid of xml_errmsg remaining non-null when the
storage it points at has been deallocated.  Since this is apparently
only intended as debug support, maybe we could compile it only in debug
builds, to reduce the probability that it will fail in production?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: recent --with-libxml support
Next
From: tomas@tuxteam.de
Date:
Subject: Re: quick review