I wrote:
SQL has the following escape syntax for it:
U&'special character: \' [ UESCAPE '\' ]
Here is an in-progress patch for this. It still needs updates in the
psql scanner and possibly other scanners. But the server-side
functionality works.
Index: doc/src/sgml/syntax.sgml
===
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Thu, Oct 23, 2008 at 06:04:43PM +0300, Peter Eisentraut wrote:
>> Yeah, excellent question. It seems completely unnecessary, but it is
>> surely there in the syntax diagram.
> Probably because many Unicode representations are done with "U+"
> foll
On Thu, Oct 23, 2008 at 06:04:43PM +0300, Peter Eisentraut wrote:
>> Man that's ugly. Why the ampersand?
>
> Yeah, excellent question. It seems completely unnecessary, but it is
> surely there in the syntax diagram.
Probably because many Unicode representations are done with "U+"
followed by 4-
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> 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, f
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
SQL has the following escape syntax for it:
U&'special character: \' [ UESCAPE '\' ]
Man that's ugly. Why the ampersand?
Yeah, excellent question. It seems completely unnecessary, but it is
surely there in the syntax dia
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> SQL has the following escape syntax for it:
> U&'special character: \' [ UESCAPE '\' ]
Man that's ugly. Why the ampersand? How do you propose to distinguish
this from a perfectly legitimate use of the & operator?
> 2. Convert this syntax to
I would like to add an escape mechanism to PostgreSQL for entering
arbitrary Unicode characters into string literals. We currently only
have the option of entering the character directly via the keyboard or
cut-and-paste, which is difficult for a number of reasons, such as when
the font doesn'
