From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Tom Dunstan <pgsql(at)tomd(dot)cc>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Enums patch v2 |
Date: | 2006-12-19 15:19:34 |
Message-ID: | 23973.1166541574@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> 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.
Remember that the value has to be decodable by the output routine.
So the only way we could do that would be by creating a separate output
function for each enum type. (That is, a separate pg_proc entry
... they could all point at the same C function, which would have to
check which OID it was called as and work backward to determine the enum
type.)
While this is doubtless doable, it's slow, it bloats pg_proc, and
frankly no argument has been offered that's compelling enough to
require it. The alignment issue takes enough air out of the
space-saving argument that it doesn't seem sufficient to me.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2006-12-19 15:22:13 | Re: [HACKERS] Enums patch v2 |
Previous Message | Andrew Dunstan | 2006-12-19 15:11:42 | Re: [HACKERS] Enums patch v2 |
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2006-12-19 15:22:13 | Re: [HACKERS] Enums patch v2 |
Previous Message | Andrew Dunstan | 2006-12-19 15:11:42 | Re: [HACKERS] Enums patch v2 |