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

From Sam Mason
Subject Re: Catastrophic changes to PostgreSQL 8.4
Date
Msg-id 20091203160332.GG5407@samason.me.uk
Whole thread Raw
In response to Re: Catastrophic changes to PostgreSQL 8.4  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Thu, Dec 03, 2009 at 10:46:54AM -0500, Tom Lane wrote:
> 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).

I agree it'll be fine most of the time and the more important thing is
normally the data rather than the filename.  Still, for non-english
speaking people I'd guess there are many more encodings floating around
than I'd ever expect to see on a daily basis.  Us English/US speakers
really do have a very easy life.

There's also the issue that the user's encoding doesn't necessarily
match the system's encoding.  Thus within an account everything may be
easy, but when a system daemon comes in and looks at things it's going
to be somewhat messy.

No hard numbers either way, I just know I see a very biased sample of
systems and would not like to make generalizations.

> 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.

Yup, be interesting to hear more details from the OP about this.

--
  Sam  http://samason.me.uk/

pgsql-general by date:

Previous
From: Ivan Sergio Borgonovo
Date:
Subject: Re: [Bacula-users] Catastrophic changes to PostgreSQL 8.4
Next
From: Tom Lane
Date:
Subject: Re: numeric cast oddity