From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Procedure additions to ParseFuncOrColumn are inadequate |
Date: | 2018-06-15 19:00:35 |
Message-ID: | 14497.1529089235@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
tighten-object-type-checks-in-ParseFuncOrColumn.patch | text/x-diff | 6.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-06-15 19:04:18 | Re: pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding |
Previous Message | Andrew Gierth | 2018-06-15 18:47:01 | Re: BUG #15237: I got "ERROR: source for a multiple-column UPDATE item must be a sub-SELECT or ROW() expression" |