Skip site navigation (1) Skip section navigation (2)

Loose ends in PG XML patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, "Nikolay Samokhvalov" <samokhvalov(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Loose ends in PG XML patch
Date: 2006-12-24 01:44:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-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

* 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

In response to


pgsql-hackers by date

Next:From: Christopher BrowneDate: 2006-12-24 02:03:11
Subject: Re: Autovacuum Improvements
Previous:From: Tom LaneDate: 2006-12-24 01:22:40
Subject: Re: recent --with-libxml support

pgsql-committers by date

Next:From: Tom LaneDate: 2006-12-24 16:39:01
Subject: Re: Loose ends in PG XML patch
Previous:From: Tom LaneDate: 2006-12-24 00:57:48
Subject: pgsql: Fix machine-dependent crash in sqlchar_to_unicode().

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group