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 xmloption xml_recv ditto (OK already) xml_out correctly(?) marked IMMUTABLE xml_send is STABLE, OK because it depends on client_encoding texttoxml should be STABLE because it depends on xmloption xmltotext 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

Peter Eisentraut <peter_e@gmx.net> writes: > Tom Lane wrote: >> Should we force initdb to correct these pg_proc entries, or just quietly >> change pg_proc.h? > Considering the extent of the changes, I'd be in favor of forcing an initdb. Well, if you're going to change the contents of pg_cast then there is little choice. I was considering something less invasive ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster