Re: [GENERAL] possible to create multivalued index from xpath() results in 8.3? - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [GENERAL] possible to create multivalued index from xpath() results in 8.3?
Date
Msg-id 200711211320.08713.peter_e@gmx.net
Whole thread Raw
Responses Re: [GENERAL] possible to create multivalued index from xpath() results in 8.3?
List pgsql-hackers
Am Mittwoch, 21. November 2007 schrieb Tom Lane:
> "Matt Magoffin" <postgresql.org@msqr.us> writes:
> > Ugh, you're right of course! Somehow I had this wrong. So I tried to
> > create an index on the xml[] result by casting to text[] but I got the
> > "function must be immutable" error. Is there any reason the xml[] to
> > text[] cast is not immutable?
>
> Hmm ... I see that xmltotext() is marked 'stable' in pg_proc.h,
> but texttoxml() is marked 'immutable', which is at best inconsistent.
> It looks to me like they both depend on the GUC setting "xmloption",
> which would mean they should both be stable.  Peter, is there a bug
> there?

Yeah, that doesn't look right.

> Also, is there a way to get rid of the GUC dependency so that 
> there's a reasonably safe way to index XML values?

We could drop the dependency in xmltotext() with little loss of functionality.  
The spec doesn't allow casts between xml and text (varchar) at all.  The way 
I appear to have derived the current behavior from the spec is that this is 
interpreted as an implicit XMLSERIALIZE call in the context of a prepared 
statement, which is defined to observe the XML option, as per clause 17.3 
(part 14).  This was the clostest piece of spec that described conversion 
from xml to character types.  Now with the xpath functionality, there is 
certainly a strong use case for ignoring this altogether and just serializing 
with the XML option set to "content".

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: plperl failure on OS X 10.5(.1)
Next
From: Alvaro Herrera
Date:
Subject: Re: VACUUM/ANALYZE counting of in-doubt tuples