Re: [GENERAL] possible to create multivalued index from xpath() results in 8.3?
| От | Tom Lane |
|---|---|
| Тема | Re: [GENERAL] possible to create multivalued index from xpath() results in 8.3? |
| Дата | |
| Msg-id | 10361.1195658858@sss.pgh.pa.us обсуждение |
| Ответ на | Re: [GENERAL] possible to create multivalued index from xpath() results in 8.3? (Peter Eisentraut <peter_e@gmx.net>) |
| Ответы |
Re: [GENERAL] possible to create multivalued index from xpath() results in 8.3?
|
| Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes:
> 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".
Given the actual behavior of xmltotext_with_xmloption, it certainly
seems like a pretty useless error check. Also, xml_out doesn't behave
that way, so why should xmltotext?
The volatility markings of xml_in and texttoxml seem wrong too.
It looks to me like we need:
xml_in should be STABLE because it depends on xmloptionxml_recv ditto (OK already)xml_out correctly(?)
markedIMMUTABLExml_send is STABLE, OK because it depends on client_encodingtexttoxml should be STABLE because it
dependson xmloptionxmltotext remove xmloption dependency, mark as IMMUTABLE
Should we force initdb to correct these pg_proc entries, or just quietly
change pg_proc.h?
regards, tom lane
В списке pgsql-hackers по дате отправления: