On 02/28/2011 05:28 PM, Kevin Grittner wrote:
Anton<antonin.hou...@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.



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to