Robert Haas wrote:
> On Mon, Feb 28, 2011 at 10:30 AM, Tom Lane <tgl@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.
Someone should measure how much overhead the indexing of xml values
might have. If it is minor, we might be OK with only an indexed xml
type.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
