From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Kaare Rasmussen <kar(at)kakidata(dot)dk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Enums again |
Date: | 2005-11-08 14:18:05 |
Message-ID: | 4370B39D.60100@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera wrote:
>Andrew Dunstan wrote:
>
>
>
>>In the catalog, pg_type would
>>get a new column of type text[] that would hold the list of values, and
>>typtype would have a new possible value of 'e' for enumeration. There
>>might be other consequential changes too, but I think that would be most
>>of it.
>>
>>
>
>Huh, why not have the actual values in a separate catalog like
>pg_enumvalues or some such?
>
>
Sure, could do that. I don't have strong feelings either way.
>
>
>>The only functions that actually need to have any knowledge of
>>the enumeration strings are the input/output functions and the to/from
>>text casts. These would get the relevant info from fcinfo.flinfo ... and
>>then looking up the type cache - not sure yet if an extra cache
>>operation is needed.
>>
>>
>
>It'd be interesting to measure the difference of having the cache vs.
>not having it.
>
>
Possibly. I would expect it to make a noticeable difference.
>Thinking on how to pg_dump the whole thing is important too.
>
>
>
Yes, that would certainly be part of the work. I should have mentioned
that. It's not a showstopper, though - I see no reason in principal for
it to be a difficulty.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2005-11-08 14:20:12 | Re: [Pgsphere-dev] Re: SIGSEGV taken on 8.1 during dump/reload |
Previous Message | Robert Creager | 2005-11-08 14:11:39 | Re: SIGSEGV taken on 8.1 during dump/reload |