Re: Enum proposal / design

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Enum proposal / design
Дата
Msg-id 44E4669A.1020808@dunslane.net
обсуждение исходный текст
Ответ на Re: Enum proposal / design  (Greg Stark <gsstark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: pgstattuple extension for indexes
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCHES] WIP: bitmap indexes