Re: show() function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Joe Conway <mail(at)joeconway(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: show() function
Date: 2002-06-28 03:28:04
Message-ID: 2115.1025234884@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> I'd like to see us *not* overload "opaque" with yet another meaning;
>> see past rants on subject. But as long as there was a distinguishable
>> representation of "returns void" in pg_proc, I'd see no problem with the
>> above.

> I am aware of this concern. However, 0 is the most natural way to encode
> "nothing" in PostgreSQL. Moreover, it would be desirable to be able to
> declare trigger "routines" as procedures rather than opaque-returning
> functions, so to preserve compatibility we'd have to make them equivalent.

Say what? Trigger routines do not return void ...

> To un-overload type OID 0, the unknown and C string types should be
> changed to other numbers.

Type OID 0 should only be used for "no type at all", as in the unused
slots of an oidvector, or the unused input-type column of a unary
operator. "Returns void" is a distinct concept, as is "returns tuple"
(or however you want to define the result of a trigger), as certainly
is C string. Unknown already has an OID.

I have speculated about inventing a notion of "pseudo types" (perhaps
marked by 'p' in typtype) that would be allowed as function input and/or
result types but not as column datatypes. Then we could create distinct
pseudotypes with distinct OIDs for each of these shades of meaning.

regards, tom lane

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Christopher Kings-Lynne 2002-06-28 03:33:17 Re: [HACKERS] Non-standard feature request
Previous Message Neil Conway 2002-06-27 23:31:56 pg_dump: fix 2 memory leaks