Re: enums - Mailing list pgsql-hackers

From Gregory Maxwell
Subject Re: enums
Date
Msg-id e692861c0510272302g689db8d0uca13e3897dd82b86@mail.gmail.com
Whole thread Raw
In response to Re: enums  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: enums
List pgsql-hackers
On 10/27/05, Andrew Dunstan <andrew@dunslane.net> 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 without
> >the brokenness as much as possible unless we have good cause
> >otherwise.
> >
>
> mmm ... no. It is too broken. We should do enums orthogonally with other
> type definitions in PostgreSQL. Where I would like to get to is that we
> have a flavor of CREATE TYPE that will create the enum type for us,
> including all the support that I build into my little kit. And if you
> want to change the enumeration set on a column, you would use ALTER
> TABLE foo ALTER COLUMN  bar  TYPE newtype USING ...

eh, Well that we have a reasonable user extensiable type system is
reasonable reason.  What I was mostly objecting to was the use of
lexical collation the "don't mess with what people already expect"
argument was just the most handy strawman available. :)

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.

> Inline declarations of enums does not strike me as good.

You're right, it's a property of a type.


pgsql-hackers by date:

Previous
From: Gavin Sherry
Date:
Subject: Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",
Next
From: Matteo Beccati
Date:
Subject: Re: ERROR: invalid memory alloc request size