From: | Tom Dunstan <pgsql(at)tomd(dot)cc> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Enums patch v2 |
Date: | 2006-12-20 01:39:58 |
Message-ID: | 4588946E.90505@tomd.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Alvaro Herrera wrote:
> I don't, because there are always those that are knowledgeable enough to
> know how to reduce space lost to padding. So it would be nice to have
> 2-byte enums on-disk, and resolve them based on the column's typid. But
> then, I'm not familiar with the patch at all so I'm not sure if it's
> possible.
Not with this patch, and AFAIK not possible generally, without writing
separate I/O functions for each type. I'd love to be able to do that,
but I don't think it's possible currently. The main stumbling block is
the output function (and cast-to-text function), because output
functions do not get provided the oid of the type that they're dealing
with, for security reasons IIRC. It was never clear to me why I/O
functions should ever be directly callable by a user (and hence open to
security issues), but apparently it was enough to purge any that were
designed like that from the system, so I wasn't going to go down that
road with the patch.
Cheers
Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2006-12-20 01:44:26 | Re: effective_cache_size vs units |
Previous Message | Matthew O'Connor | 2006-12-20 01:33:59 | Re: Autovacuum Improvements |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Dunstan | 2006-12-20 02:00:48 | Re: Enums patch v2 |
Previous Message | Tom Dunstan | 2006-12-20 01:23:02 | Re: Enums patch v2 |