On Wed, 2009-05-06 at 18:33 +0300, Peter Eisentraut wrote:
> On Tuesday 05 May 2009 17:38:33 Tom Lane wrote:
> > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> > > Bernd Helmle <mailings@oopsware.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.
And we can also escape the need to uncompress TOAST'ed fields - just
markup the compression as another \c at the beginning of data.
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability Services, Consulting and Training
