From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
Cc: | drewk(at)cockroachlabs(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18463: Possible bug in stored procedures with polymorphic OUT parameters |
Date: | 2024-05-15 00:00:31 |
Message-ID: | 1631943.1715731231@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I wrote:
> Some experimentation showed that we need to return the correct
> output column names in this tupdesc, so continuing to use
> build_function_result_tupdesc_t seems like the easiest path for that.
> However, stmt->outargs does hold nodes of the correct resolved data
> types, so overwriting the atttypid's from that produces a nicely
> small patch, as attached.
Bleah ... that works fine back to v14, but in 12 and 13 it falls
down because there's no outargs list in CallStmt. We can look at
stmt->funcexpr->args instead, but (a) we have to rediscover which
elements of that are output args, and (b) that list hasn't been
run through expand_function_arguments, so we have to do that
an extra time.
(b) is pretty annoying, since the work is 100% duplicative of
what's about to happen in ExecuteCallStmt. I thought briefly
about moving the expand_function_arguments call from execution to
transformCallStmt, the way it's done in v14 and later. I'm afraid
to do that though, because it seems just barely possible that there's
third-party code that knows that that list hasn't been expanded in
these old branches. I fear we just have to eat the additional
cycles. They're not that much compared to what will happen to run
a user-defined procedure, but still, bleah.
So I end with the attached modification for 12/13.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
fix-polymorphic-procedure-outputs-v13.patch | text/x-diff | 6.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2024-05-15 00:28:28 | BUG #18466: Wrong row estimate for nested loop |
Previous Message | Melanie Plageman | 2024-05-14 23:33:18 | Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae |