From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | "Alvaro Herrera" <alvherre(at)atentus(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: cash_out bug |
Date: | 2002-08-12 05:30:38 |
Message-ID: | 27732.1029130238@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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
From | Date | Subject | |
---|---|---|---|
Next Message | Don Baccus | 2002-08-12 05:31:40 | Re: OOP real life example (was Re: Why is MySQL more chosen |
Previous Message | Hannu Krosing | 2002-08-12 05:29:21 | Re: OOP real life example (was Re: Why is MySQL more |