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 по дате отправления: