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
