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 по дате отправления: