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
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 |