Martijn van Oosterhout <kleptog@svana.org> writes:
> On Thu, Jun 29, 2006 at 03:54:36PM +0200, Thomas Hallgren wrote:
> > I have to concur with this. Assume you use a bytea for a UUID that in
> > turn is used as a primary key. The extra overhead will be reflected in
> > all indexes, all foreign keys, etc. In a normalized database some tables
> > may consist of UUID columns only.
>
> So you create a UUID type. It's cheap enough to create new types after
> all, that's one of postgresql's strengths. What I'm saying is that it's
> easier to create new fixed length types for the cases that need it,
> than it is to redo the entire type handling of the backend.
I guess my motivation here is that I feel currently char(n) is basically
broken in Postgres. Sure it satisfies the letter of the specification, but
it's failing to actually achieve anything for the users. There's no point at
all in using char(n) in Postgres since it takes exactly the same amount of
space as varchar() if you're always stuffing it full and more space if you're
not.
In the current setup the only reason for Postgres to have this data type at
all is purely for legacy compatibility. It doesn't actually "work" in that it
doesn't provide the space savings it's intended to and that would give users
an actual reason to use it in new databases.
--
greg
