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: 4D6C1FEE.7040608@gmail.com (view raw or flat)
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

Responses

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-2014 The PostgreSQL Global Development Group