Re: Escape handling in COPY, strings, psql - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Escape handling in COPY, strings, psql
Date
Msg-id 200505292000.20723.peter_e@gmx.net
Whole thread Raw
In response to Re: Escape handling in COPY, strings, psql  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Escape handling in COPY, strings, psql  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Escape handling in COPY, strings, psql  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian wrote:
> >  I am thinking the only clean solution is to add a special keyword
> > like ESCAPE before strings that contain escape information.  I
> > think a GUC is too general.  You know if the string is a constant
> > if it contains escapes just by looking at it, and if it is a
> > variable, hopefully you know if it has escapes.

I do support gradually phasing out backslash escapes in standard string 
literals in the interest of portability.  Most of the current escape 
sequences are of limited value anyway.  Let's think about ways to get 
there:

Enabling escape sequences in string literals controls the formatting of 
input (and output?) data, so it is akin to, say, the client encoding 
and the date style, so a GUC variable isn't out of the question in my 
mind.  It makes most sense, though, if we want to eventually make users 
switch it off all the time, that is, as a transition aid.  But before 
that can happen, we need to come up with an alternative mechanism to 
enter weird characters.

One such way may be to provide functions (say, chr(), tab(), etc.) to 
give access to unprintable characters, but that will result in terrible 
performance for long strings and it also won't help with COPY or places 
where only literals are allowed.

Another way would be to allow escape sequences only in specially marked 
strings.  The proposal above doing 'foo' ESCAPE 'x' seems fairly 
elegant for SQL linguists but would be pretty weird to implement in the 
lexer.  It won't help with COPY either, but that is really the case for 
all solutions.

A more compact represenation may be using a prefix letter, like E'foo'.  
This fits the SQL syntax, is familiar with Python programmers (although 
in the other direction), and can be implemented efficiently in the 
lexer.  I like that the best, personally.

For COPY, we would probably have to use a flag in the COPY command 
itself either way (like already done for NULL AS).

Comments?  Other ideas?  Keep the escapes?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Simplifying unknown-literal handling
Next
From: Andrew - Supernews
Date:
Subject: Re: Simplifying unknown-literal handling