On Mon, Mar 14, 2016 at 8:48 AM, Alvaro Herrera <alvhe...@2ndquadrant.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.
