Procedure additions to ParseFuncOrColumn are inadequate
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2018-06-15T19:00:35Z
Lists: pgsql-hackers
Attachments
- tighten-object-type-checks-in-ParseFuncOrColumn.patch (text/x-diff) patch
I noticed that ParseFuncOrColumn isn't terribly thorough about rejecting
non-procedure results when proc_call is true. Since the caller is just
assuming that it gets back what it expects, that leads to core dumps
or worse:
regression=# call int4(42);
server closed the connection unexpectedly
This probably means the server terminated abnormally
Also, with the existing ad-hoc approach to this, not all the ereports
are alike; the one for an aggregate lacks the HINT the others provide.
Also, in the cases where it does successfully reject should-be-procedure
or should-not-be-procedure, it reports ERRCODE_UNDEFINED_FUNCTION, which
seems quite inappropriate from here: I'd expect ERRCODE_WRONG_OBJECT_TYPE.
There's also a pre-existing oversight that when we get a result of
FUNCDETAIL_COERCION, we should reject that if there's any aggregate
decoration, but we fail to.
The attached cleans all this up; any objections?
regards, tom lane
Commits
-
Fix some minor error-checking oversights in ParseFuncOrColumn().
- 0dcf68e5a1f1 11.0 landed