Re: bytea vs. pg_dump

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: bytea vs. pg_dump
Дата
Msg-id 19471.1241542306@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: bytea vs. pg_dump  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: bytea vs. pg_dump  (Greg Stark <greg.stark@enterprisedb.com>)
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> I'm thinking plain old pairs-of-hex-digits might be the best
>> tradeoff if conversion speed is the criterion.  The main problem
>> in any case would be to decide how to control the format option.

> Yeah.  Any ideas on how to do that? I can't think of anything very clean 
> offhand.

Well, there's nothing much wrong with a GUC setting to control output
--- we have lots of precedent, such as DateStyle.  The problem is with
figuring out what ambiguous input is meant to be.  There seems to be
an uncomfortably high risk of misinterpreting the input.

For sake of argument, suppose we define the hex format as "0x followed
by pairs of hex digits".  We could then modify byteaout so that if it
were told to print in old-style a value that happened to start with
"0x", it could output "0\x" instead, which means the same but would be
unambiguous.  This would fix the problem going forward, but old-style
dumps and un-updated clients would still be at risk.  The risk might
not be too high though, since the odds of successfully parsing old-style
data as hex would be relatively low, particularly if we were draconian
about case (ie the "x" MUST be lower case and the hex digits MUST be
upper).
        regards, tom lane


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

Предыдущее
От: "Emmanuel Cecchet"
Дата:
Сообщение: Wrong stats for empty tables
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Wrong stats for empty tables