Sorry got top-posting -- stupid iphone mail client.
We could eliminate the problem with old dumps by doing something like
\x to indicate a new-style hex dump.
That doesn't make us 100% safe against arbitrary user input but should
be pretty low risk.
--
Greg
On 5 May 2009, at 18:51, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
