Thread: 'select @1' problem

As for the 'select @1' problem:

785                             targetOid = func_select_candidate(1, &arg,
candidates);
786                             tup = SearchSysCacheTuple(OPRNAME,
787
PointerGetDatum(op),
788
ObjectIdGetDatum(InvalidOid),
789
ObjectIdGetDatum(*targetOid),
790
CharGetDatum('l'));
(gdb) print targetOid
$1 = (unsigned int *) 0x0

Ahem... dereferencing a NULL? Bad bad bad.

PARSEDEBUG gives:

unary_oper_get_candidates: start scan for '@'
unary_oper_get_candidates: found candidate '@' for type float4
unary_oper_get_candidates: found candidate '@' for type float8
unary_oper_get_candidates: found 2 candidates
func_select_candidate- candidate has 0 matches
func_select_candidate- choose candidate as best match
func_select_candidate- candidate has 0 matches
func_select_candidate- choose candidate as possible match
func_select_candidate- column #0 input type is int4

Anyone know where the error is supposed to be generated?

JP Sugarbroad

> Ahem... dereferencing a NULL? Bad bad bad.

No kidding, eh? :)

postgres=> select @1;
?column?
--------
       1
(1 row)

I had paid more attention to the binary operators when re-doing the
operator matching and implicit type coersion stuff for this release. So,
the binary operators were using new code, while the unary operators were
still reusing the function matching code rather than the new dedicated
operator matching code.

Also, the left-hand operator code was not checking for a null return
from the function/operator matching code, so core dumped rather than
throwing a graceful error message.

So two problems have been fixed: the core dump when unable to find a
single best match, and the inability to find a good match for this test
case.

Will apply patches after regression testing (but it can't be worse than
before).

Thanks for spotting the problem...

                       - Tom