Re: bytea vs. pg_dump

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, "Bernd Helmle" <mailings(at)oopsware(dot)de>
Subject: Re: bytea vs. pg_dump
Date: 2009-05-06 15:33:03
Message-ID: 200905061833.04003.peter_e@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tuesday 05 May 2009 17:38:33 Tom Lane wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> > Bernd Helmle <mailings(at)oopsware(dot)de> wrote:
> >> Another approach would be to just dump bytea columns in binary
> >> format only (not sure how doable that is, though).
> >
> > If that's not doable, perhaps a base64 option for bytea COPY?
>
> 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.

The output format can be controlled by a GUC parameter. And while we are at
it, we can also make bytea understand the new output format on input, so we
can offer an end-to-end alternative to the amazingly confusing current bytea
format and also make byteain() equally faster at the same time.

For distinguishing various input formats, we could use the backslash to escape
the format specification without breaking backward compatibilty, e.g.,

'\hexd41d8cd98f00b204e9800998ecf8427e'

With a bit of extra work we can wrap this up to be a more or less SQL-
conforming blob type, which would also make a lot of people very happy.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-05-06 15:34:49 Re: Some questions about PostgreSQL source code
Previous Message Tom Lane 2009-05-06 15:20:06 Re: text_pattern_ops and complex regexps