Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group