Re: Catastrophic changes to PostgreSQL 8.4 - Mailing list pgsql-general

From Tom Lane
Subject Re: Catastrophic changes to PostgreSQL 8.4
Date
Msg-id 9441.1259855214@sss.pgh.pa.us
Whole thread Raw
In response to Re: Catastrophic changes to PostgreSQL 8.4  (Sam Mason <sam@samason.me.uk>)
Responses Re: Catastrophic changes to PostgreSQL 8.4  (Sam Mason <sam@samason.me.uk>)
Re: Catastrophic changes to PostgreSQL 8.4  (Kern Sibbald <kern@sibbald.com>)
List pgsql-general
Sam Mason <sam@samason.me.uk> writes:
> As others have said; BYTEA is probably the best datatype for you to
> use.  The encoding of BYTEA literals is a bit of a fiddle and may need
> some changes, but it's going to be much more faithful to your needs of
> treating the filename as an opaque blob of data.

bytea might be theoretically the best choice, but the fact remains that
99% of the entries will be text that's readable in the user's encoding
(whatever that is).  bytea will just be a serious PITA because of its
escaping issues.  Also, the fact that 8.5 may change to hex display by
default will make bytea even more of a PITA for mostly-text data.
So I think Bacula's choice to use sql_ascii with text columns is
entirely defensible.

What concerns me is the claim that PG made a database with some
arbitrary parameters after having rejected a now-considered-invalid
command.   I frankly do not believe that, but if it did happen it's
a *serious* bug that requires investigation.

            regards, tom lane

pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Catastrophic changes to PostgreSQL 8.4
Next
From: Scott Marlowe
Date:
Subject: Re: numeric cast oddity