Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter

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