Excerpts from Joseph Adams's message of lun jun 07 17:16:12 -0400 2010:
> > However, for a built-in enum type, I agree with Robert's solution of
> > just #define-ing fixed OIDs for the values of the type.
>
> I don't know if the JSON datatype will be a contrib module or built-in
> yet, but if it were contrib, would it still be better to use fixed
> OIDs anyway?
If it were contrib, fixed OIDs wouldn't cut it precisely for that
reason. (A contrib module is not "built-in" for these purposes.)
> One issue with setting this precedent is that new
> contrib modules using enums wouldn't be compatible with older versions
> of PostgreSQL. One idea might be to insert extend CREATE TYPE name AS
> ENUM so OIDs can be specified explicitly, but then that could lead to
> OID clashes. That would be a really messy problem for users.
Yeah. We've just defined an interface for pg_migrator-only usage,
allowing it to define the OID values of ENUMs; it wasn't considered a
good idea to expose the details to the user.
> By the way, just curious: why can't the internal representation of an
> enum just be an INT starting from 0 by default, like in C? That would
> make a heck of a lot more sense, in my opinion. It might also allow
> users to do things like this in the future:
>
> CREATE TYPE number AS ENUM ('one' = 1, 'two' = 2, 'three' = 3);
The problem is that the output function needs to be able to figure out
the value starting with only the datum value. If it had only the "1"
it couldn't know what enum it'd correspond to. The other alternative
would have been to make enums 64 bits wide, carrying the enum OID in 32
bits and the value in the other 32. This was dismissed as too wasteful.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
