Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> SQL has the following escape syntax for it:
>> U&'special character: \xxxx' [ UESCAPE '\' ]
>
> Man that's ugly. Why the ampersand?
Yeah, excellent question. It seems completely unnecessary, but it is
surely there in the syntax diagram.
> How do you propose to distinguish
> this from a perfectly legitimate use of the & operator?
Well, technically, there is going to be some conflict, but the practical
impact should be minimal because:
- There are no spaces allowed between U&' . We typically suggest spaces
around binary operators.
- Naming a column "u" might not be terribly common.
- Binary-and with an undecorated string literal is not very common.
Of course, I have no data for these assertions. An inquiry on -general
might give more insight.
>> 2. Convert this syntax to a function call. But that would then create a
>> lot of inconsistencies, such as needing functional indexes for matches
>> against what should really be a literal.
>
> Uh, why do you think that? The function could surely be stable, even
> immutable if you grant that a database's encoding can't change.
Yeah, true, that would work.
There are some other disadvantages for making a function call. You
couldn't use that kind of literal in any other place where the parser
calls for a string constant: role names, tablespace locations,
passwords, copy delimiters, enum values, function body, file names.
There is also a related feature for Unicode escapes in identifiers, and
it might be good to keep the door open on that.
We could to a dual approach: Convert in the scanner when server encoding is UTF8, and pass on as function call
otherwise. Surely ugly though.
Or pass it on as a separate token type to the analyze phase, but that is
a lot more work.
Others: What use cases do you envision, and what requirements would they
create for this feature?