Re: Enum proposal / design

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

In response to

Browse pgsql-hackers by date

  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