Re: [PATCHES] Adding \x escape processing to COPY, psql, backend - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [PATCHES] Adding \x escape processing to COPY, psql, backend
Date
Msg-id 200505302015.j4UKFke23797@candle.pha.pa.us
Whole thread Raw
Responses Re: [PATCHES] Adding \x escape processing to COPY, psql, backend  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Here is a new version of the three \x hex support patches.  I have added
> > \x for psql variables, which is the last patch.
> 
> > I have IM'ed with Peter and he is now OK with the idea of supporting \x,
> > with the underestanding that it doesn't take us any farther away from
> > compatibility than we are now.
> 
> Peter may be OK with it, but I object strongly to adding this to SQL
> literals.  This is exactly *not* the direction we want to be going in.
> 
> I don't really see the point for COPY and psql, either.

We already support \n, \r, \t, and \octal.  I don't see any problem with
improving it.  It does not take us any closer or farther away from spec
compliance.

COPY \x has been requested by several people, and there are actually two
patches that have been submitted in the past year for this.

As you know, escapes already provide a useful mechanism on COPY and SQL
strings, and there is a plan I just posted to deal with standards
issues, but I don't see \x taking us closer or farther from this.

Please explain why this takes us in the wrong direction.

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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Backslash handling in strings
Next
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] Inherited constraints and search paths (was