On Fri, Jun 18, 2010 at 1:59 PM, Andrew Dunstan <and...@dunslane.net> wrote: > > > Robert Haas wrote: >> >> On Fri, Jun 18, 2010 at 12:59 PM, Andrew Dunstan <and...@dunslane.net> >> wrote: >> >>> >>> You are just bumping up the storage cost. Part of the attraction of enums >>> is >>> their efficiency. >>> >> >> What's efficient about them? Aren't we using 4 bytes to store a value >> that will nearly always fit in 2, if not 1? >> >> > > This was debated when we implemented enums. As between 1,2 and 4 there is > often not much to choose, as alignment padding makes it pretty much the > same. But any of them are more efficient than storing a numeric value or the > label itself. > > Anyway, it might well be moot. > > cheers > > andrew
Something I don't understand in all this is: why can't the type of an enum be determined statically rather than stored in every single value? For instance, if we have: CREATE TYPE number AS ENUM ('one', 'two', 'three'); CREATE TYPE color AS ENUM ('red', 'green', 'blue'); PostgreSQL won't allow a comparison between two different enum types, e.g.: > SELECT 'one'::number = 'red'::color; ERROR: operator does not exist: number = color However, when we say: SELECT 'one'::number = 'one'::number Couldn't enum_eq just use get_fn_expr_argtype to determine the type of enum input rather than rely on it being stored in the value (either implicitly via OID or explicitly as a word half)? Also, I can't seem to find the original debates from when enums were implemented. Does anyone have a link to that thread in the archives? Thanks. Joey Adams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers