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.
