"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Is it worth starting a thread about it at this stage? It
> is a pretty serious problem.
I agree, but given the lack of movement over the last couple years,
I'm not expecting a solution to suddenly emerge for 7.3 ...
> 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
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> 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 differ
> It turns out to be a far more serious bug than that, and is not limited
> to cash_out. All these functions have the same problem:
>
> select proname from pg_proc where proargtypes=(select proargtypes from
> pg_proc where proname='cash_in') and pronargs=1 and proisstrict='t'
> order by proname;
I said:
> It turns out to be a far more serious bug than that, and is not limited
> to cash_out. All these functions have the same problem:
>
> With a few exceptions (the test(*) is long, as it requires one to wait for
> the database to start after testing each function, but there are 16 out
>
Hello:
I was investigating the bug about "select cash_out(2)" crashing the
backend. I thought fixing was a simple matter of checking whether some
argument to the function was NULL or not.
I added a NULL checking, but it obviously is not triggered, because the
data received is not NULL, but a no
