Re: Escape handling in COPY, strings, psql

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Cc: 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 13:30:06
Message-ID: 200505291330.j4TDU6C10539@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > Here is an updated version of the COPY \x patch. It is the first patch
> > > attached.
> > > Also, I realized that if we support \x in COPY, we should also support
> > > \x in strings to the backend. This is the second patch.
> >
> > Do we really want to do any of these things? We've been getting beaten
> > up recently about the fact that we have non-SQL-spec string escapes
> > (ie, all the backslash stuff) so I'm a bit dubious about adding more,
> > especially when there's little if any demand for it.
>
> I thought about that, but adding additional escape letters isn't our
> problem --- it is the escape mechanism itself that is the issue.
>
> I have wanted to post on this issue so now is a good time. I think we
> have been validly beaten up in that we pride ourselves on standards
> compliance but have escape requirement on all strings. Our string
> escapes are a major problem --- not the number of them but the
> requirement to double backslashes on input, like 'C:\\tmp'. 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.
>
> Basically, I think we have to deal with this somehow. I think it could
> be implemented by looking for the ESCAPE keyword in parser/scan.l and
> handling it all in there by ignoring backslash escapes if ESCAPE
> preceeds the string. By the time you are in gram.y, it is too late.

One other idea would be to remove escape processing for single-quoted
strings but keep it for our $$ strings, becuase they are not ANSI
standard.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2005-05-29 14:19:59 compiling postgres with Visual Age compiler on OpenPower5 / Linux
Previous Message Peter Eisentraut 2005-05-29 11:36:54 Re: Escape handling in COPY, strings, psql

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2005-05-29 15:15:49 Re: Escape handling in COPY, strings, psql
Previous Message Neil Conway 2005-05-29 13:27:33 skip FK trigger on UPDATE