Currently we don't have a way to create a GIN index on an array of
enums, or to use an enum field in a GIST index, so it can't be used in
an exclusion constraint, among other things.
I'd like to work on fixing that if possible. Are there any insuperable
barriers? If not, what do we need to
Andrew Dunstan andrew at dunslane.net writes:
If people would like to play, I have created a little kit to help in
creating first class enum types in a few seconds.
Isn't what we actually want possreps?
---(end of broadcast)---
TIP 6: explain
Leandro Guimarães Faria Corcete DUTRA wrote:
Andrew Dunstan andrew at dunslane.net writes:
If people would like to play, I have created a little kit to help in
creating first class enum types in a few seconds.
Isn't what we actually want possreps?
You appear to be
Maybe I missed it, but I didn't see any conclusion. If I want to design
an Open Source system now that may be in beta in three to six months and
I'd like to use enums, is this a good place to look?
There's no way you're going to be using enums.
I guess I'm wondering about the kit going into
Just don't use enums - they're awful.
In general?
So, instead of using enums for order states or originating system, I'll user
numbers or text? Or implement lookup tables ?
---(end of broadcast)---
TIP 1: if posting/reading through Usenet,
So, instead of using enums for order states or originating system, I'll
user numbers or text? Or implement lookup tables ?
Use a text field and a CHECK constraint if you have just a couple of
states, and a lookup table if you have many.
Always use a lookup table if you plan on adding new
Christopher Kings-Lynne wrote:
Maybe I missed it, but I didn't see any conclusion. If I want to
design an Open Source system now that may be in beta in three to six
months and I'd like to use enums, is this a good place to look?
There's no way you're going to be using enums.
I guess I'm
Andrew Dunstan wrote:
In the catalog, pg_type would
get a new column of type text[] that would hold the list of values, and
typtype would have a new possible value of 'e' for enumeration. There
might be other consequential changes too, but I think that would be most
of it.
Huh, why not
Alvaro Herrera wrote:
Andrew Dunstan wrote:
In the catalog, pg_type would
get a new column of type text[] that would hold the list of values, and
typtype would have a new possible value of 'e' for enumeration. There
might be other consequential changes too, but I think that would be
Andrew Dunstan [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
Huh, why not have the actual values in a separate catalog like
pg_enumvalues or some such?
Sure, could do that. I don't have strong feelings either way.
I'd vote for the separate catalog instead of bloating pg_type.
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
Huh, why not have the actual values in a separate catalog like
pg_enumvalues or some such?
Sure, could do that. I don't have strong feelings either way.
I'd vote for the separate
Also, Christopher - I was somewhat motivated to work on this by your
recent comment about enums being the number one demand of migrating
MySQL users, so I am mildly amused by your last sentence ;-)
They're not mutually exclusive statements :)
---(end of
I've been going through the thread that Andrew Dunstan started with his
enumkit.
Maybe I missed it, but I didn't see any conclusion. If I want to design an
Open Source system now that may be in beta in three to six months and I'd
like to use enums, is this a good place to look?
I guess I'm
On 10/27/05, Andrew Dunstan [EMAIL PROTECTED] wrote:
Yes, MySQL is broken in some regards, as usual. However, the API isn't
bad (except for the fact that it doesn't care what invalid crap you
throw at it), and more importantly there are thousands of apps and
developers who think around that
Gregory Maxwell wrote:
And in doing so you could insert a enum in the middle of the existing
list without breaking the values already in the table? If so that
would be very useful.
You do it by altering the column type, not by altering the type itself.
MySQL's way of doing this is made
Andrew wrote:
Jim C. Nasby wrote:
Personally, I don't see why enum can't just be syntactic sugar on top
of
a side-table of values and a foreign key. And I guess a view to hide
the
internals from normal viewing. That would certainly allow the most
flexibility, although it probably wouldn't
Rod Taylor wrote:
The other issue is ease of use.
We used lookup tables in bugzilla when it was converted to work with
Postgres. But many users will find having to do that annoying, to say
the least. I think there's a very good case for providing true enums.
Then why did you use
On Thu, Oct 27, 2005 at 11:07:19PM -0400, Rod Taylor wrote:
The other issue is ease of use.
We used lookup tables in bugzilla when it was converted to work with
Postgres. But many users will find having to do that annoying, to say
the least. I think there's a very good case for
On Thu, Oct 27, 2005 at 10:34:57PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
On Thu, Oct 27, 2005 at 09:45:05PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
Andrew, you mentioned that if you want to change the ordering you should
just create a new type. What
On Fri, 2005-10-28 at 13:20 -0500, Jim C. Nasby wrote:
On Thu, Oct 27, 2005 at 11:07:19PM -0400, Rod Taylor wrote:
The other issue is ease of use.
We used lookup tables in bugzilla when it was converted to work with
Postgres. But many users will find having to do that annoying, to
Jim C. Nasby wrote:
But why force a re-write of the entire table just to change the name of
something?
Because you are not just changing the name of something.
No, I was refering specifically to the case of wanting to rename
something. IE: you setup an enum for sky
On Fri, Oct 28, 2005 at 02:57:03PM -0400, Rod Taylor wrote:
The basic idea is that most of us break out schemas by creating fake
primary keys for the purpose of obtaining performance because using the
proper primary key (single or multiple columns) is often very slow.
The automatic and
On Fri, Oct 28, 2005 at 04:12:01PM -0400, Andrew Dunstan wrote:
Well, with enumkit you can't, because the values are hardwired in the
.so file. With a builtin facility you would be able to, because the
values would live in the catalog. However, hacking the catalog is not
something I would
Jim C. Nasby wrote:
On Fri, Oct 28, 2005 at 04:12:01PM -0400, Andrew Dunstan wrote:
Well, with enumkit you can't, because the values are hardwired in the
.so file. With a builtin facility you would be able to, because the
values would live in the catalog. However, hacking the catalog is
On Fri, 2005-10-28 at 15:21 -0500, Jim C. Nasby wrote:
On Fri, Oct 28, 2005 at 02:57:03PM -0400, Rod Taylor wrote:
The basic idea is that most of us break out schemas by creating fake
primary keys for the purpose of obtaining performance because using the
proper primary key (single or
On Fri, Oct 28, 2005 at 04:36:26PM -0400, Rod Taylor wrote:
On Fri, 2005-10-28 at 15:21 -0500, Jim C. Nasby wrote:
On Fri, Oct 28, 2005 at 02:57:03PM -0400, Rod Taylor wrote:
The basic idea is that most of us break out schemas by creating fake
primary keys for the purpose of obtaining
On Fri, 2005-10-28 at 16:28 -0500, Jim C. Nasby wrote:
On Fri, Oct 28, 2005 at 04:36:26PM -0400, Rod Taylor wrote:
On Fri, 2005-10-28 at 15:21 -0500, Jim C. Nasby wrote:
On Fri, Oct 28, 2005 at 02:57:03PM -0400, Rod Taylor wrote:
The basic idea is that most of us break out schemas by
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
If people would like to play, I have created a little kit to help in
creating first class enum types in a few seconds. It works something
like this:
make TYPENAME=rainbow ENUMS=' red, orange, yellow, green,
blue, indigo, violet '
make TYPENAME=rainbow install
psql -f
This is cool; it's something people can use today if nothing else.
Long-term, is it practical to have the enums compiled in? ISTM that's
not very workable, but I'm completely guessing. The other issue is that
this version makes it very difficult to change what's in the enum (not
that that's at all
This little snippet is great! The only problem I see is that the enums must be consistent across all modules.
What about loading a variable with a default value? Then it could be adjusted to 'play'.On 10/27/05, Jim C. Nasby
[EMAIL PROTECTED] wrote:This is cool; it's something people can use
On Thu, Oct 27, 2005 at 04:54:36PM -0400, Ted Rolle wrote:
This little snippet is great! The only problem I see is that the enums must
be consistent across all modules.
What about loading a variable with a default value? Then it could be
adjusted to 'play'.
Huh? Sorry, but you completely
Adding -hackers back to the list...
-Original Message-
From: Gregory Maxwell [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 27, 2005 5:03 PM
To: Jim Nasby
Subject: Re: [HACKERS] enums
On 10/27/05, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Thu, Oct 27, 2005 at 04:54:36PM
On 10/27/05, Jim Nasby [EMAIL PROTECTED] wrote:
Adding -hackers back to the list...
You could as equally say that it's ordering it by the order of the
enum declaration, which seems quite reasonable to me.
I don't really see why that's considered reasonable, especially as a default.
I
Jim C. Nasby wrote:
On another note, I noticed that the comparison operators seem to be
comparing the underlying numeric value used to store the enum, which is
wrong IMO. Consider:
ENUM color 'red,blue,green'
CREATE TABLE t (c color);
INSERT INTO t VALUES('blue');
INSERT INTO t
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
Gregory Maxwell wrote:
Yes, MySQL is broken in some regards, as usual. However, the API isn't
bad (except for the fact that it doesn't care what invalid crap you
throw at it), and more importantly there are thousands of apps and
developers who think around that interface. We should copy it
Jim C. Nasby wrote:
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.
I do not see this at all. An enumeration defines an ordering and a
On Thu, Oct 27, 2005 at 07:02:45PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
On another note, I noticed that the comparison operators seem to be
comparing the underlying numeric value used to store the enum, which is
wrong IMO. Consider:
ENUM color 'red,blue,green'
CREATE TABLE t (c
On Thursday 2005-10-27 16:22, Andrew Dunstan wrote:
Jim C. Nasby wrote:
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.
I do not see this at
On Oct 28, 2005, at 9:23 , Trent Shipley wrote:
On Thursday 2005-10-27 16:22, Andrew Dunstan wrote:
Jim C. Nasby wrote:
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
Trent Shipley wrote:
An enumeration is just a computer science short-hand way to define a set and a
native collation for the set.
An enumeration's native collation need not be the only, or even the most
common, collation for the enumerated set of symbols.
No it's not. Many
On Thu, Oct 27, 2005 at 05:41:01PM -0600, Michael Fuhr wrote:
If you want values ordered lexically then you can enumerate them
that way. Why force that behavior on people who want to order based
on some other criteria?
Well, I was arguing about the default behavior. I'd bet that we're going
: Re: [HACKERS] enums
Trent Shipley wrote:
An enumeration is just a computer science short-hand way to define a set
and a
native collation for the set.
An enumeration's native collation need not be the only, or even the most
common, collation for the enumerated set of symbols.
No it's
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
Cristian Prieto wrote:
What about use the declaration order as the enum order?, for example: if I
declare something like: CREATE ENUM hola ('item1', 'item3', 'item2');
-this is just assuming an hypothetical approach to use enum types in this
way- and the logical order of the items could be
On Thursday 2005-10-27 17:39, Michael Glaesemann wrote:
On Oct 28, 2005, at 9:23 , Trent Shipley wrote:
On Thursday 2005-10-27 16:22, Andrew Dunstan wrote:
Jim C. Nasby wrote:
snip/
Relational databases already have a type for unordered sets: tables.
IMO, if there's going to be a separate
On Thu, Oct 27, 2005 at 09:45:05PM -0400, Andrew Dunstan wrote:
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
Ted Rolle wrote:
This little snippet is great! The only problem I see is that the
enums must be consistent across all modules.
What about loading a variable with a default value? Then it could
be adjusted to 'play'.
You can set a default for a variable using one of these types, as
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,
Jim C. Nasby wrote:
On Thu, Oct 27, 2005 at 09:45:05PM -0400, Andrew Dunstan wrote:
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
The other issue is ease of use.
We used lookup tables in bugzilla when it was converted to work with
Postgres. But many users will find having to do that annoying, to say
the least. I think there's a very good case for providing true enums.
Then why did you use lookup tables instead of a
On 10/27/05, Andrew Dunstan [EMAIL PROTECTED] wrote:
That seems counter-intuitive. It's also exposing an implimentation
detail (that the enum is stored internally as a number).
No it is not. Not in the slightest. It is honoring the enumeration order
defined for the type. That is the ONLY
53 matches
Mail list logo
