Skip site navigation (1) Skip section navigation (2)

Re: Native XML

From: Anton <antonin(dot)houska(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Native XML
Date: 2011-02-28 22:21:34
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On 02/28/2011 05:23 PM, Robert Haas wrote:
> On Mon, Feb 28, 2011 at 10:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

In response to


pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-02-28 22:28:22
Subject: Re: Native XML
Previous:From: Josh BerkusDate: 2011-02-28 22:05:08
Subject: Re: Re: Why our counters need to be time-based WAS: WIP: cross column correlation ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group