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
