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