From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql(at)tomd(dot)cc, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Enum proposal / design |
Date: | 2006-08-17 12:52:42 |
Message-ID: | 44E4669A.1020808@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark wrote:
> "Tom Dunstan" <pgsql(at)tomd(dot)cc> writes:
>
>
>> I didn't really want to go down that path in this thread
>> since it would turn what should be a fairly non-intrusive
>> patch to add a new type into a big thing, and I really just
>> wanted to get enums in. :) I tend to think of it the other
>> way around from how you put it: if a general solution to
>> that problem can be found which does fall afoul of the
>> security issues that were the reason for multi-argument
>> output functions to be killed off in the first place, then
>> great, and enums can directly benefit.
>>
>
> True. Perhaps it's reasonable to use a 8-byte representation in the name of
> getting the user-visible feature in. Knowing that the fundamental problem will
> eventually be solved and the implementation can eventually be improved
> transparently to use 1 to 4 byte storage.
>
>
8 bytes is dead. We are going with 4 bytes, which will in fact be an oid
which will uniquely identify a <typeoid,value> combination.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-08-17 12:54:00 | Re: [PATCHES] WIP: bitmap indexes |
Previous Message | Martijn van Oosterhout | 2006-08-17 12:23:48 | Re: pgstattuple extension for indexes |