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 по дате отправления: