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?  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Postgres 8.3 archive_command
Следующее
От: "Albe Laurenz"
Дата:
Сообщение: Re: backup_label and server start