Re: Native XML

On 02/28/2011 05:28 PM, Kevin Grittner wrote:
> Anton<antonin.houska@gmail.com>  wrote:
>
>> it was actually the focal point of my considerations: whether to
>> store plain text or 'something else'.
>


There seems to be an almost universal assumption that storing XML in its 
native form (i.e. a text stream) is going to produce inefficient 
results. Maybe it will, but I think it needs to be fairly convincingly 
demonstrated. And then we would have to consider the costs. For example, 
unless we implemented our own XPath processor to work with our own XML 
format (do we really want to do that?), to evaluate an XPath expression 
for a piece of XML we'd actually need to produce the text format from 
our internal format before passing it to some external library to parse 
into its internal format and then process the XPath expression. That 
means we'd actually be making things worse, not better. But this is 
clearly the sort of processing people want to do - see today's 
discussion upthread about xpath_table.

I'm still waiting to hear what it is that the OP is finding hard to do 
because we use libxml2.


> Given that there were similar issues for other hierarchical data
> types, perhaps we need something similar to tsvector, but for
> hierarchical data.  The extra layer of abstraction might not cost
> much when used for XML compared to the possible benefit with other
> data.  It seems likely to be a very nice fit with GiST indexes.
>
> So under this idea, you would always have the text (or maybe byte
> array?) version of the XML, and you could "shard" it to a separate
> column for fast searches.
>
>


Tsearch should be able to handle XML now. It certainly knows how to 
recognize XML tags.

cheers

andrew