Skip site navigation (1) Skip section navigation (2)

Re: enums

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: Michael Fuhr <mike(at)fuhr(dot)org>, ted(at)php(dot)net,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: enums
Date: 2005-10-28 01:45:05
Message-ID: 436182A1.7050806@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

Jim C. Nasby wrote:

>Andrew, you mentioned that if you want to change the ordering you should
>just create a new type. What about if you need to change the values that
>are in the enum? MySQL does (or at least did, it's been some time since
>I've messed with this) a horrible job at that. There's no way to rename
>anything; you have to add the new names you want, then do a bulk update,
>then delete the (now old) names. IMO this is broken.
>  
>


It would just be a standard "ALTER TABLE foo ALTER COLUMN bar TYPE 
newtype USING expression" operation. You would write a function that 
took a value of the old type and returned a value of the new type and 
use a cll to that function in the expression. Since these would be named 
types, unlike the case in mysql where they are anonymously defined 
inline, this would present no difficulties at all.

>Also, if we are going to maintain ordering and mapping (presumably via
>the internal number that we're storing), then I think we should expose
>that, at least optionally. So for example, you should be able to define
>what a specific enum value means. Not everyone will want a linear
>numbering starting at 0 afterall.
>  
>

What on earth for? Users should not care in the slightest what the 
internal representation is . Users who want a map where the values are 
exposed should create a lookup table.

You keep saying that we are using the internal representation as the 
ordering. This is simply the wrong way to look at it. The internal 
representation REFLECTS the ordering; it doesn't impose it. The user has 
imposed the ordering when defining the type. In my enumkit I did provide 
a function that gave back the internal representation, but I am not by 
any means certain that that's a good idea.

cheers

andrew

In response to

  • Re: enums at 2005-10-28 01:24:57 from Jim C. Nasby

Responses

  • Re: enums at 2005-10-28 02:14:15 from Jim C. Nasby

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2005-10-28 01:46:41
Subject: Re: enums
Previous:From: Jim C. NasbyDate: 2005-10-28 01:37:22
Subject: Re: TODO Item - Add system view to show free space map contents

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group