Tom Lane <tgl@sss.pgh.pa.us> writes:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > I am looking at creating a few generic functions builtin for the enum
> > stuff. These would be tied to each enum type as it is created. However,
> > they should not really appear in pg_proc initially, as there wouldn't be
> > any enum types to tie them to anyway. But I want them to have reserved
> > oids and appear in the list of builtins.
>
> This feels wrong to me. Ways that might work include:
>
> 1. Invent a pseudotype 'anyenum' comparable to 'anyarray', and define
> the generic functions as taking 'anyenum'.
>
> 2. Don't try to define the generic operations as true functions, but
> make them special syntactic constructs comparable to ROW() or ARRAY[].
how about 3. Have the functions take an integer and include a cast from enum
to integer.
I know the tendency has been to want to discourage implicit casts, but I think
this is a good use for them. The whole point of enums is to have syntactic
sugar over integers that let you use nicer syntax but that imposes minimal
additional complexity over simply using integers.
Maybe my conception of enums is different from yours. My conception is
basically that of C enums. Where they're purely a creature of the syntax and
type system. At run-time they don't make any effort to prevent you from
treating them as integers.
--
greg