Should we add this to /contrib?
> I've packaged up what I've done so far and you can find it at
> The TODO file included indicates what still remains to be done (a lot!).
> In particular, it would be good to implement more of the XPath grammar.
> However, once we get into the realm of more complex paths there becomes a
> question about optimisation of XPath selection. If the documents are
> pre-parsed, then XPath query elements can be rewritten as SQL queries and
> you get the optimisation of the planner on your side.
> I'd like to stick with the current solution if possible, because I think
> it delivers a very simple interface to the user and is (code-wise) also
> very straightforward. Maybe less efficient queries are a penalty worth paying?
> Any thoughts?
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2001-07-26 21:38:23|
|Subject: Re: Bad timestamp external representation|
|Previous:||From: Joel Burton||Date: 2001-07-26 20:37:06|
|Subject: RE: LIBPQ on Windows and large Queries|