"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
> Is this a problem in that the functions are definined to return opaque (eg.
> PG_RETURN_VOID) but are then still usable in SELECT statements?
The issue here is (once again) that we're overloading type oid 0
("opaque") to mean too many different, incompatible things. I've
ranted about this before and will not repeat my previous remarks.
The bottom line is that we need to eliminate "opaque" in favor of
a set of pseudo-datatypes with different, crisply-defined semantics.
We've had some discussions about it but no complete proposal has been
made. Since eliminating "opaque" is going to break just about every
extant user-defined datatype, I'm not in a hurry to do it until we
can get it right the first time...
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Don Baccus||Date: 2002-08-12 05:31:40|
|Subject: Re: OOP real life example (was Re: Why is MySQL more chosen|
|Previous:||From: Hannu Krosing||Date: 2002-08-12 05:29:21|
|Subject: Re: OOP real life example (was Re: Why is MySQL more|