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

Re: enums

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Rod Taylor <pg(at)rbt(dot)ca>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,Michael Fuhr <mike(at)fuhr(dot)org>
Subject: Re: enums
Date: 2005-10-28 22:21:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Oct 28, 2005 at 06:10:26PM -0400, Rod Taylor wrote:
> It isn't supposed to impact the external representation of the data and
> generally neither is an ENUM outside of the potential sorting ability. I
> was just getting the impression that the big push for enums was to be
> able to use a 'real word' but without a performance hit.
> A regular old table, foreign key to a varchar gives you the 'real word'
> and the surrogate key allows you to do so without a performance hit.

I think there's probably good use cases for each. If you've got
something small like a status field, 'enum' might be better. For bigger
things, SURROGATE could be nice syntactic sugar.

Now that I finally understand what Andrew's been getting at with enums,
I'm wondering if we might want to expand on the typical usage a bit.
Looking at a plain-old C enum, you're just representing some magic
labels with a number to save space. Things like say, SLRU_PAGE_CLEAN,
a code standpoint, but they're not something you'd typically want to
display to the user. So, imho a useful extension would be to allow for
enums to contain both the 'machine name' and a 'human name', where the
human name could be renamed freely. To put this in a more concrete
example; I hate the default priorities that ship with bugzilla; P1 - P5.
Is 1 high or is 5? So I always rename them to Very Low, Low ... Very
High. That means making changes both to the database and to the code.
But if Bugzilla was using my idea of an enum then the code would refer
to priorities with P1...P5 (or whatever else they wanted to call it) and
I could easily change the human names to something that can't be
Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
Pervasive Software    work: 512-231-6117
vcard:       cell: 512-569-9461

In response to

  • Re: enums at 2005-10-28 22:10:26 from Rod Taylor

pgsql-hackers by date

Next:From: Josh BerkusDate: 2005-10-28 22:41:38
Subject: TODO for plpgsql: RETURN should accept arbitrary composite expressions
Previous:From: Rod TaylorDate: 2005-10-28 22:10:26
Subject: Re: enums

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