Re: show() function - Mailing list pgsql-patches

From Tom Lane
Subject Re: show() function
Date
Msg-id 2115.1025234884@sss.pgh.pa.us
Whole thread Raw
In response to Re: show() function  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-patches
Peter Eisentraut <peter_e@gmx.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



pgsql-patches by date:

Previous
From: nconway@klamath.dyndns.org (Neil Conway)
Date:
Subject: pg_dump: fix 2 memory leaks
Next
From: "Christopher Kings-Lynne"
Date:
Subject: Re: [HACKERS] Non-standard feature request