Re: Enums again

Christopher Kings-Lynne wrote:

>> Maybe I missed it, but I didn't see any conclusion. If I want to 
>> design an Open Source system now that may be in beta in three to six 
>> months and I'd like to use enums, is this a good place to look?
>
>
> There's no way you're going to be using enums.
>
>> I guess I'm wondering about the kit going into PgFoundry, being 
>> accepted in the main branch or being dropped. And the timeframe for 
>> all that.
>
>
> Time frame is more like 18 months.  The kit is also very rough - not 
> like a finished feature would be like at all.  Plus, there's no 
> guarantee the feature would ever make it into postgres.
>
> Just don't use enums - they're awful.
>
>

Well, perhaps I should speak ;-)

First, enumkit is not intended for pgfoundry or contrib. It's a 
byproduct of some research I was doing. It occurred to me that making 
what I had done generic would be very simple - the only variables in 
fact are the type name and the list of enumeration values. So I spent 30 
minutes making it generic and enumkit was born.

So of course it's rough - it is a research workproduct, not finished code.

Now, my intention is to use that work product as part of allowing first 
class enumeration types. Currently the proposal is till in my head, but 
basically it would involve a fairly small set of changes. There would 
(probably) need to be a new unreserved keyword plus a new rule set in 
the grammar to allow for type creation, 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. 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. I haven't yet worked out how to build the qsorted 
table that enumkit uses for bsearch lookup on input, or even whether it 
is worth doing. And I haven't done a line of code. Like I say it's all 
in my head right now.

As for the timeframe - if this direction is acceptable I want to get it 
into 8.2. I really hope that 8.2 is not 18 months away. I think we 
should aim for a release cycle no longer than a year. This last cycle 
worked pretty well, and I think we should try to repeat it. But within 6 
months ... no.

So ... since Kaare asks, would a feature along the lines I outlined 
above be acceptable? And does anyone have an alternative proposal that 
they are prepared to work on?

If the answer to both of these is "no", then I will probably produce a 
patch at some stage that would be hosted on pgfoundry. But that would be 
far from ideal.

BTW, does the standard have a way of doing this? ISTR hearing something 
about distinct types. If so, what should the grammar look like, and can 
we use it (or something close)? I'd rather not just invent syntax freely.

Also, Christopher - I was somewhat motivated to work on this by your 
recent comment about enums being the number one demand of migrating 
MySQL users, so I am mildly amused by your last sentence ;-)

cheers

andrew