Re: BUG #15373: null / utf-8

Поиск
Список
Период
Сортировка
От 'Bruce Momjian'
Тема Re: BUG #15373: null / utf-8
Дата
Msg-id 20180914022033.GD23686@momjian.us
обсуждение исходный текст
Ответ на Re: BUG #15373: null / utf-8  ('Bruce Momjian' <bruce@momjian.us>)
Ответы AW: BUG #15373: null / utf-8
Список pgsql-bugs
On Sat, Sep  8, 2018 at 04:36:19PM -0400, 'Bruce Momjian' wrote:
> On Sat, Sep  8, 2018 at 09:43:18PM +0200, André Hänsel wrote:
> > For some reason the example given in the documentation for the "hex"
> > format uses such an "escape string literal":
> > 
> > SELECT E'\\xDEADBEEF';
> > 
> > I found this very confusing. Can this example be changed to a normal
> > string literal, like this?
> > 
> > SELECT '\xDEADBEEF';
> 
> You know, I 100% agree with you.  We used the E'' syntax so we would
> produce the same results whether standard_conforming_strings was true or
> false.  However, we changed the standard_conforming_strings default to
> true in Postgres 9.1 on 2011-09-12, and that release has been
> end-of-life for a year.
> 
> I think it is time to clarify our documentation examples by assuming
> that standard_conforming_strings is true.  I will work on a patch. 
> Thanks.

I have developed the attached documentation patch to remove the E''
syntax.  standard_conforming_strings defaulted to 'on' in PG 9.1.

I also found that our bytea data type section wasn't properly adjusted
when we changed the the default bytea_output to 'hex' in PG 9.0.

I think the only question is how far back to apply this patch.  I am
thinking through 9.3.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Андрей Ковальчук
Дата:
Сообщение: Re: BUG #15382: Error create dictionary in pg_dump
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query