type coercion of record types

From: Arne Roland <arne(dot)roland(at)malkut(dot)net>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: type coercion of record types
Date: 2026-07-29 22:23:45
Message-ID: 2dd221e7-0ad5-48ad-a736-396734aeb5af@malkut.net
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi all,

I was migrating some code to test my custom postgres branch and stumbled
into this upstream issue about type coercion.

Here a simple reproducer

CREATE TABLE tab (a int, b int);
    CREATE FUNCTION f() RETURNS tab LANGUAGE sql
      AS $$ SELECT j FROM (SELECT 1 AS a, 2 AS b) j $$;

Since SIGSEGV is fairly annoying, even on a test database, I did some
digging. It seems, that the changes in the coercion mechanics caused
this. Apparently this is around since the typemod function rework
shortly discussed here
(https://www.postgresql.org/message-id/flat/18929(dot)1574895430(at)sss(dot)pgh(dot)pa(dot)us)

Looking at this, I convinced myself, that a new case in
coerce_fn_result_column (only for the RECORDOID) might be a way to
address this. But I am not sure how to do this without passing the
entire parse back to it additionally.

Side note maybe a fallback in coerce_record_to_complex on pstate == NULL
could make this an error instead of a segfault, which would have been
good enough for my use case, since the rewrite is almost trivial. Maybe
that's the better route.

Regards
Arne

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrey Rachitskiy 2026-07-30 01:40:20 Re: BUG #19586: money division overflow
Previous Message PG Bug reporting form 2026-07-29 17:55:45 BUG #19587: hashchar (internal "char" type) depends on platform char signedness