Re: enum bug

On Mon, Mar 14, 2016 at 8:48 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> Joshua D. Drake wrote:
> > On 03/11/2016 03:19 PM, Elein wrote:
> >
> > >An unused (yet) enum type cannot display the enum ranges. An empty table
> > >containing that type cannot display enum ranges.
> > >
> > >The example selects were what I did to figure out that enum_ranges only
> > >worked on existing data. Sorry if they were confusing. But the way enum
> > >values are currently displayed is confusing.
> > >
> > >Enums are evil because of the difficulty working with them. They should
> > >be used for a fixed set of valid values. Otherwise use a lookup table.
> >
> > "Otherwise use a lookup table."
> >
> > That is the solution to this problem.
>
> You know, I suspect this Elein person may know a bit about these
> database thingies(*).
>
> I don't think she is complaining because she cannot find her way around
> designing a garment color table; rather it seems to me she is pointing
> out actual problems in our design of the enum feature because she would
> like to see it improve. If improved enough, maybe we could get to a
> point where they could actually be used; otherwise why the heck did we
> let the feature in the database in the first place? I think all these
> "use a lookup table, you silly!" answers are missing the point.
>
>
​I still cannot figure out what the actual problem is that a lookup table
is the solution.

We already have a way to show all the possible enum values for a given enum
independent of whether it is use in a table or not.

The fact that we requiring passing a null instance instead of an OID might
be unusual but our recent json_to_record stuff does the exact same thing so
unusually or not it is (now?) idiomatic PostgreSQL.

David J.