Re: BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Tender Wang <tndrwang@gmail.com>, exclusion@gmail.com,
pgsql-bugs@lists.postgresql.org
Date: 2024-04-12T03:46:49Z
Lists: pgsql-bugs
Richard Guo <guofenglinux@gmail.com> writes: > On Thu, Apr 11, 2024 at 10:13 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I did think about that, but it seems mighty weird. The semantics of >> the flag would have to be something like "I want a tupdesc when the >> result type is COMPOSITE, but not when it's RECORD", which seems >> rather arbitrary. > Indeed. I did actually spend some time today trying to code that up, to see what it would look like. The attempt failed though, because there are existing cases in which get_expr_result_type() returns TYPEFUNC_RECORD, so we can't use that result code as a positive indicator that "this RTE has a coldeflist". In a green field we could invent another TYPEFUNC_XXX code, but that's not a back-patchable idea. So the new function would need some independent indicator that it saw a coldeflist, and at that point there's basically nothing we're hiding from the callers. >> Perhaps it'd be sufficient to add a note to the header comment of >> get_expr_result_type warning about when not to use it. > Works for me. OK, barring other objections I'll push forward on that basis. regards, tom lane
Commits
-
Fix type-checking of RECORD-returning functions in FROM, redux.
- e0df80828abc 17.0 landed
- e0970862e868 12.19 landed
- cc1eb6a3cccd 16.3 landed
- b6e21cef72f1 13.15 landed
- 78e81e14db79 14.12 landed
- 09989ba84734 15.7 landed