Re: BUG #19470: PostgreSQL backend aborts (assert failure) when a prepared statement returns a composite type cast t

Hi,

On Tue, May 5, 2026 at 11:37 AM Euler Taveira <euler(at)eulerto(dot)com> wrote:
> On Wed, Apr 29, 2026, at 8:27 AM, PG Bug reporting form wrote:
> >
> > Reproduction steps (minimal):
> > BEGIN;
> > CREATE TYPE foo AS (a int, b text);
> > PREPARE p AS SELECT CAST(ROW(1, 'hello') AS foo)::text;
> > EXECUTE p;
> > ALTER TYPE foo ALTER ATTRIBUTE a TYPE VARCHAR(100);
> > EXECUTE p;
> > COMMIT;
> >
>
> Thanks for your report! The attached patch fixes this case. I included a
> similar test case but I'm fine if the test is not included with this fix. I
> decided to create a separate function instead of adding the new conditions to
> record_plan_type_dependency() because it keeps the fix simple and isolated.
>
> The crash is reproduced back to v11 which means this fix should be backpatched
> to all supported versions.

Thanks for working on this.

I think this is on the right track. Using relationOids is the right
mechanism, since the DDL doesn't touch the composite's pg_type row and
a TYPEOID inval item wouldn't work here. Doing it in fix_expr_common
covers extract_query_dependencies too.

What I'm less easy about is whether Const and RowExpr are the only
carriers. As written, the TYPTYPE_COMPOSITE test won't look through an
array over a composite or a domain over one, and nodes like
FieldSelect and ConvertRowtypeExpr also carry composite type OIDs.
Could you check whether any of those reproduce a similar crash? If so
we'd want to look through to the element/base type and/or cover more
node types before this goes in.

Modulo that, I'll prepare to push to all supported branches.

--
Thanks, Amit Langote