Andrew Dunstan <and...@dunslane.net> writes: > On 02/28/2011 04:25 AM, Anton wrote: >> 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. Well, in principle we could allow them to work on both, just the same way that (for instance) "+" is a standardized operator but works on more than one datatype. But I agree that the prospect of two parallel types with essentially duplicate functionality isn't pleasing at all. I think a reasonable path forwards for this work would be to develop and extend the non-libxml-based type as an extension, outside of core, with the idea that it might replace the core implementation if it ever gets complete enough. The main thing that that would imply that you might not bother with otherwise is an ability to deal with existing plain-text-style stored values. This doesn't seem terribly hard to do IMO --- one easy way would be to insert an initial zero byte in all new-style values as a flag to distinguish them from old-style. The forced parsing that would occur to deal with an old-style value would be akin to detoasting and could be hidden in the same access macros. > 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. Agreed. The single most pressing problem we've got with XML right now is the poor state of the XPath extensions in contrib/xml2. If we don't see a meaningful step forward in that area, a new implementation of the xml datatype isn't likely to win acceptance. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers