Andrew Dunstan <[EMAIL PROTECTED]> writes: >> Um ... so that means CONVERT(c USING y) now fails entirely? That might >> be going a bit far. If we do want to get rid of that syntax then I'm >> noting a lack of parser changes in this patch.
> No, that's still there. The only change there is that it returns a > bytea. I forgot to put that in the commit notes. :-( The SQL99 spec is pretty definite that it returns text. I think we have a problem here. <form-of-use conversion> ::= CONVERT <left paren> <character value expression> USING <form-of-use conversion name> <right paren> a) <form-of-use conversion> shall be simply contained in a <value expression> that is immediately contained in a <derived column> that is immediately contained in a <select sublist> or shall immediately contain either a <simply value specification> that is a <host parameter name> or a <value specification> that is a <host parameter specification>. b) A <form-of-use conversion name> shall identify a form-of-use conversion. c) The declared type of the result is variable-length character string with implementation-defined maximum length. The character set of the result is the same as the character repertoire of the <character value expression> and form-of- use determined by the form-of-use conversion identified by the <form-of-use conversion name>. Let CR be that character repertoire. The result has the Implicit coercibility characteristic and its collating sequence is the default collating sequence of CR. OTOH we may be talking at cross-purposes --- on looking into gram.y I see that this syntax is transformed to a call of convert_using(), which may mean it has nothing to do with your changes. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match