Re: Enum proposal / design - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Enum proposal / design
Date
Msg-id 44E4669A.1020808@dunslane.net
Whole thread Raw
In response to Re: Enum proposal / design  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark wrote:
> "Tom Dunstan" <pgsql@tomd.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



pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: pgstattuple extension for indexes
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] WIP: bitmap indexes