Andrew Dunstan <andrew@dunslane.net> 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
immediatelycontained in a <derived column> that is immediately contained in a <select sublist>
orshall 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-definedmaximum 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
identifiedby the <form-of-use conversion name>. Let CR be that character repertoire. The result
hasthe Implicit coercibility characteristic and its collating sequence is the default collating
sequenceof 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