From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | Tender Wang <tndrwang(at)gmail(dot)com>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF |
Date: | 2024-04-12 03:46:49 |
Message-ID: | 330608.1712893609@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Thu, Apr 11, 2024 at 10:13 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2024-04-12 06:41:30 | Re: BUG #18426: Canceling vacuum while truncating a relation leads to standby PANIC |
Previous Message | Richard Guo | 2024-04-12 03:25:49 | Re: BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF |