Re: bytea vs. pg_dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Bernd Helmle <mailings(at)oopsware(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: bytea vs. pg_dump
Date: 2009-05-05 16:51:46
Message-ID: 19471.1241542306@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-05-05 16:52:23 Re: Wrong stats for empty tables
Previous Message Emmanuel Cecchet 2009-05-05 16:27:55 Wrong stats for empty tables