On 02/28/2011 04:25 AM, Anton wrote:
On 02/27/2011 11:57 PM, Peter Eisentraut wrote:
On sön, 2011-02-27 at 10:45 -0500, Tom Lane wrote:
Hmm, so this doesn't rely on libxml2 at all? Given the amount of pain
that library has caused us, getting out from under it seems like a
mighty attractive idea.
This doesn't replace the existing xml functionality, so it won't help
getting rid of libxml.
Right, what I published on github.com doesn't replace the libxml2
functionality and I didn't say it does at this moment. The idea is to
design (or rather start designing) a low-level XML API on which SQL/XML
functionality can be based. As long as XSLT can be considered a sort of
separate topic, then Postgres uses very small subset of what libxml2
offers and thus it might not be that difficult to implement the same
level of functionality in a new way.
In addition, I think that using a low-level API that Postgres
development team fully controls would speed-up enhancements of the XML
functionality in the future. When I thought of implementing some
functionality listed on the official TODO, I was a little bit
discouraged by the workarounds that need to be added in order to deal
with libxml2 memory management. Also parsing the document each time it's
accessed (which involves parser initialization and finalization) is not
too comfortable and eventually efficient.
A question is of course, if potential new implementation must
necessarily replace the existing one, immediately or at all. What I
published is implemented as a new data type and thus pg_type.h and
pg_proc.h are the only files where something needs to be merged. From
technical point of view, the new type can co-exist with the existing easily.
This however implies a question if such co-existence (whether temporary
or permanent) would be acceptable for users, i.e. if it wouldn't bring
some/significant confusion. That's something I'm not able to answer.
The only reason we need the XML stuff in core at all and not in a
separate module is because of the odd syntax requirements of SQL/XML.
But those operators work on the xml type, and not on any new type you
might invent.
Which TODO items were you trying to implement? And what were the blockers?
We really can't just consider XSLT, and more importantly XPath, as
separate topics. Any alternative XML implementation that doesn't include
XPath is going to be unacceptably incomplete, IMNSHO.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
