Re: type coercion of record types

Arne Roland <arne(dot)roland(at)malkut(dot)net> writes:
> 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 $$;

Hmm, interesting. "git bisect" agrees that this started to crash at

913bbd88dc6b859c70ebb48107b38d693c4c6673 is the first bad commit
commit 913bbd88dc6b859c70ebb48107b38d693c4c6673 (HEAD)
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Wed Jan 8 11:07:53 2020 -0500

Improve the handling of result type coercions in SQL functions.

Before that it failed with

ERROR: return type mismatch in function declared to return tab
DETAIL: Final statement returns record instead of integer at column 1.
CONTEXT: SQL function "f"

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.

regards, tom lane