Re: Native XML

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