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

Re: Native XML

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Anton <antonin(dot)houska(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Native XML
Date: 2011-03-01 13:16:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Feb 28, 2011 at 6:54 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> 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.

Well, obviously the only point of having our own internal format is if
we have our own xpath processor &c to match.  One would think that
this would be a lot faster than parsing the string with libxml2 every
time we want to xpath it, especially for large documents.  But then
again, I haven't seen any benchmarks.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2011-03-01 13:20:42
Subject: Re: Sync Rep v17
Previous:From: Jan UrbaƄskiDate: 2011-03-01 10:59:38
Subject: Re: pl/python custom exceptions for SPI

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