On 02/28/2011 05:23 PM, Robert Haas wrote: > On Mon, Feb 28, 2011 at 10:30 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> 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. >> > The real issue here is whether we want to store XML as text (as we do > now) or as some predigested form which would make "output the whole > thing" slower but speed up things like xpath lookups. We had the same > issue with JSON, and due to the uncertainty about which way to go with > it we ended up integrating nothing into core at all. It's really not > clear that there is one way of doing this that is right for all use > cases. If you are storing xml in an xml column just to get it > validated, and doing no processing in the DB, then you'd probably > prefer our current representation. If you want to build functional > indexes on xpath expressions, and then run queries that extract data > using other xpath expressions, you would probably prefer the other > representation. > Yes, it was actually the focal point of my considerations: whether to store plain text or 'something else'. It's interesting to know that such uncertainty already existed in another area. Maybe it's specific to other open source projects too... > I tend to think that it would be useful to have both text and > predigested types for both XML and JSON, but I am not too eager to > begin integrating more stuff into core or contrib until it spends some > time on pgfoundry or github or wherever people publish their > PostgreSQL extensions these days and we have a few users prepared to > testify to its awesomeness. > It definitely makes sense to develop this new functionality separate for some time. It's kind of exciting to develop something new, but spending significant effort on the 'native XM' probably needs a bit higher level of consensus than what appeared in this discussion. In that context, the remark about users and their needs is something that I can't ignore.
Thanks to all for contributions to this discussion. > In any case, the definitional problems with xpath_table(), and/or the > memory management problems with libxml2, are not the basis on which we > should be making this decision. > > -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers