From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Gregory Maxwell <gmaxwell(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: enums |
Date: | 2005-10-27 23:04:48 |
Message-ID: | 20051027230448.GX63747@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 27, 2005 at 06:46:24PM -0400, Gregory Maxwell wrote:
> So what do you propose we do for a default ordering? I hope you don't
> think we should force a sort as though the enum labels were text...
I do think that. Or default ordering on whatever type the enum is (I can
see enums that are something other than text as useful, though that's a
secondary goal).
> That almost certainly incorrect for most applications of enums, which
> are used to make opaque labels more human compatible.
Sorting red before blue doesn't sound very opaque to me...
> MySQL's behavior of allowing the user to specify the collation in the
> typedef makes a lot of sense to me, it doesn't matter that it actually
> works as an artifact of the storage backend. I'd argue that it would
> make sense to sort by the specification order even if we changed the
> backend to use varchars rather than numbers.
Like I said, if we're going to support a concept of ordering of items in
an enum then we need to support it fully. For starters that means having
the ability to re-order things in an enum seamlessly.
If our primary concern is MySQL compatability then we should look at
offering two types of enums; one that mirrors their broken stuff and one
that works they way you'd actually want it to.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Grzegorz Jaskiewicz | 2005-10-27 23:14:28 | Re: _penalty gist method invoked with one key NULL |
Previous Message | Tom Lane | 2005-10-27 23:02:54 | Re: ERROR: invalid memory alloc request size <a_big_number_here> |