Re: generic builtin functions

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: generic builtin functions
Date: 2005-11-10 19:20:58
Message-ID: 87fyq4b97p.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-11-10 19:25:15 Re: generic builtin functions
Previous Message Steinar H. Gunderson 2005-11-10 19:18:51 Re: Transitive closure of a directed graph