On Tue, Dec 19, 2006 at 08:09:47AM +0000, Heikki Linnakangas wrote:
> 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.
A natural ordering is another. I'd love to be able to make a type
color that has
Red
Orange
Yellow
Green
Blue
Indigo
Violet
and then be able to do an ORDER BY color;
> 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.
Not the same thing.
> 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.
A natural ordering is precisely the use case for enums. Otherwise,
you just use a FK to a one-column table and have done.
Cheers,
D
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!
In response to
pgsql-hackers by date
| Next: | From: ITAGAKI Takahiro | Date: 2006-12-19 08:53:06 |
| Subject: Re: Dirty pages in freelist cause WAL stuck |
| Previous: | From: Magnus Hagander | Date: 2006-12-19 08:36:42 |
| Subject: Re: effective_cache_size vs units |
pgsql-patches by date
| Next: | From: ITAGAKI Takahiro | Date: 2006-12-19 09:17:10 |
| Subject: Load distributed checkpoint patch |
| Previous: | From: Simon Riggs | Date: 2006-12-19 08:47:04 |
| Subject: explain_analyze_timer |