Re: generic builtin functions
От | Greg Stark |
---|---|
Тема | Re: generic builtin functions |
Дата | |
Msg-id | 87fyq4b97p.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: generic builtin functions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: generic builtin functions
Re: generic builtin functions |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: