Re: type coercion of record types

From: Arne Roland <arne(dot)roland(at)malkut(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: type coercion of record types
Date: 2026-07-30 02:29:11
Message-ID: f1d48231-e47f-4747-9c99-8af5efa53279@malkut.net
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Tom,

thanks for your quick answer.

On 2026-07-30 4:12 AM, Tom Lane wrote:
> [...]
>
> so it's not like things were great beforehand.
>
> The proximate cause of the problem is that coerce_fn_result_column
> thinks it can pass pstate = NULL to coerce_to_target_type, which
> is specifically allowed by that function's header comment; but
> coerce_to_target_type can call coerce_record_to_complex, and that
> function's code path for a whole-row Var absolutely requires a
> valid pstate. This inconsistency seems to go back decades (at
> least to 2004).
>
> I don't see any easy way to make this work -- by the time we get
> to coerce_fn_result_column, we don't have a pstate anymore. But
> since this case has never actually worked AFAICT, maybe it's okay
> to just treat it as unsupported. I agree with fixing
> coerce_record_to_complex to do something less drastic than
> crashing, but probably we also need something in functions.c
> to provide the user-visible error report.

Is there a particular reason we can't just error right here? Why can't
we just do something like the attached patch? That seems genuinely
simple to me.

Regards
Arne

Attachment Content-Type Size
fix_coerce_record_SEGSEV.patch text/x-patch 765 bytes

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2026-07-30 02:44:56 Re: type coercion of record types
Previous Message Tom Lane 2026-07-30 02:12:12 Re: type coercion of record types