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

Re: Enums patch v2

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Dunstan <pgsql(at)tomd(dot)cc>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Enums patch v2
Date: 2006-12-19 08:09:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Tom Dunstan wrote:
> Here is an updated version of the enums patch. It has been brought up to 
> date and applies against current CVS HEAD. The original email is at [1], 
> and describes the implementation.

I'm sorry I missed the original discussions, but I have to ask: Why do 
we want enums in core? The only potential advantage I can see over using 
a look-up table and FK references is performance. And I'd rather spend 
time improving the performance of FK checks than add extra machinery to 
do the same thing in a different way.

Ignoring my general dislike of enums, I have a few issues with the patch 
as it is:

1. What's the point of having comparison operators for enums? For most 
use cases, there's no natural ordering of enum values.

2. The comparison routine compares oids, right? If the oids wrap around 
when the enum values are created, the ordering isn't what the user expects.

3. 4 bytes per value is wasteful if you're storing simple status codes 
etc. Especially if you're doing this for performance, let's do no harm 
by wasting space. One byte seems enough for the typical use cases. I'd 
even argue that having a high upper limit on the number of enum values 
encourages misuse of the feature.

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2006-12-19 08:23:23
Subject: Re: Enums patch v2
Previous:From: Zoltan BoszormenyiDate: 2006-12-19 07:43:23
Subject: Re: 8.2.0 Tarball vs. REL8_2_0 vs. REL8_2_STABLE

pgsql-patches by date

Next:From: Tom LaneDate: 2006-12-19 08:23:23
Subject: Re: Enums patch v2
Previous:From: Tom DunstanDate: 2006-12-19 02:34:36
Subject: Enums patch v2

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