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 do?
Leandro Guimarães Faria Corcete DUTRA wrote:
Andrew Dunstan 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 responding to mai
Andrew Dunstan 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 analyze
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 broadcast)-
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 cata
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.
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 mos
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
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 w
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 stat
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, ple
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 Pg
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 w
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 'r
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 schem
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 obtai
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
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 n
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 woul
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 t
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 co
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 an
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
> >>>jus
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 f
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 loo
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 wo
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
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 aroun
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 O
> 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
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 a
> > 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
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
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'
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:
> Relational databases already have a type for unordered sets: tables.
> IMO, if there's going to be a separate
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 '
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 n
e de 2005 07:06 p.m.
To: [EMAIL PROTECTED]
Cc: pgsql-hackers@postgresql.org
Subject: 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
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
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 langua
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 re-ord
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
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"'
>
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 s
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 wit
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 ar
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 VALUES(
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.
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 -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 complet
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
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
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
53 matches
Mail list logo
