Skip site navigation (1) Skip section navigation (2)

Re: Escape handling in COPY, strings, psql

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Sergey Ten <sergey(at)sourcelabs(dot)com>,"'Christopher Kings-Lynne'" <chriskl(at)familyhealth(dot)com(dot)au>,jason(at)sourcelabs(dot)com
Subject: Re: Escape handling in COPY, strings, psql
Date: 2005-05-29 18:00:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
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 

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

In response to


pgsql-hackers by date

Next:From: Andrew - SupernewsDate: 2005-05-29 18:27:59
Subject: Re: Simplifying unknown-literal handling
Previous:From: Tom LaneDate: 2005-05-29 17:24:22
Subject: Re: Simplifying unknown-literal handling

pgsql-patches by date

Next:From: Tom LaneDate: 2005-05-29 19:10:32
Subject: Re: Escape handling in COPY, strings, psql
Previous:From: Tom LaneDate: 2005-05-29 17:19:24
Subject: Re: pg_buffercache causes assertion failure

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group