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

Re: Escape handling in COPY, strings, psql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,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 19:10:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> 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:

I really don't think there is any way to get there without creating
gaping security holes in all kinds of client code :-(.  If we change
the escaping rules, then a client that is expecting some other rule
than happens to be in force will be subject to trivial SQL-injection
attacks.  This will make the autocommit fiasco pale by comparison ...

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

The spec-compatibility argument for removing escapes does not apply to
COPY at all, so I see no need to fool with the COPY definition in any

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2005-05-29 19:13:58
Subject: Re: Simplifying unknown-literal handling
Previous:From: Andrew - SupernewsDate: 2005-05-29 18:27:59
Subject: Re: Simplifying unknown-literal handling

pgsql-patches by date

Next:From: Neil ConwayDate: 2005-05-30 00:16:15
Subject: Re: skip FK trigger on UPDATE
Previous:From: Peter EisentrautDate: 2005-05-29 18:00:19
Subject: Re: Escape handling in COPY, strings, psql

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