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. 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. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers