Re: [HACKERS] bytea_output vs make installcheck
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] bytea_output vs make installcheck |
Дата | |
Msg-id | B6EEEF4B-85A4-4AE5-854D-691E804701E4@anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] bytea_output vs make installcheck (neha khatri <nehakhatri5@gmail.com>) |
Ответы |
Re: [HACKERS] bytea_output vs make installcheck
Re: [HACKERS] bytea_output vs make installcheck |
Список | pgsql-hackers |
On February 14, 2017 9:02:14 PM PST, neha khatri <nehakhatri5@gmail.com> wrote: >On Wed, Feb 15, 2017 at 10:04 AM, neha khatri <nehakhatri5@gmail.com> > wrote:. >> >> >>> Attached are two options for doing that. One overrides bytea_output >>> locally where-ever needed, and the other overrides it for the entire >>> 'regression' database. >>> >> >> The solution that overrides bytea_output locally looks appropriate. >It may >> not be required to change the format for entire database. >> Had there been a way to convert bytea_output from 'hex' to 'escape' >> internally, that could have simplified this customization even more. >> > >Well, the conversion from 'hex' to 'escape' is available using the >function >encode(). >So the queries that are failing due to the setting bytea_output = >escape, >can be wrapped under encode(), to obtain the result in 'escape' format. >Here is another way to resolve the same problem. The patch is attached. I don't quite see the point of this - there's a lot of settings that cause spurious test failures. I don't see any pointfixing random cases of that. And I don't think the continual cost of doing so overall is worth the minimal gain. What's your reason to get this fixed? Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
В списке pgsql-hackers по дате отправления: