Re: bytea vs. pg_dump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: bytea vs. pg_dump
Date
Msg-id 19471.1241542306@sss.pgh.pa.us
Whole thread Raw
In response to Re: bytea vs. pg_dump  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: bytea vs. pg_dump  (Greg Stark <greg.stark@enterprisedb.com>)
List 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 by date:

Previous
From: "Emmanuel Cecchet"
Date:
Subject: Wrong stats for empty tables
Next
From: Tom Lane
Date:
Subject: Re: Wrong stats for empty tables