Re: [PATCHES] Adding \x escape processing to COPY, psql, backend

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [PATCHES] Adding \x escape processing to COPY, psql, backend
Дата
Msg-id 200505302015.j4UKFke23797@candle.pha.pa.us
обсуждение исходный текст
Ответы Re: [PATCHES] Adding \x escape processing to COPY, psql, backend  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Backslash handling in strings
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [GENERAL] Inherited constraints and search paths (was