Horton
Menu

Re: Attribute of type record has wrong type error with MERGE ... WHEN NOT MATCHED BY SOURCE THEN DELETE

Dean Rasheed <dean.a.rasheed@gmail.com>

View thread
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tender Wang <tndrwang@gmail.com>, Duncan Sands <duncan.sands@deepbluecap.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-03-11T19:20:54Z
Lists: pgsql-bugs 
On Tue, 11 Mar 2025 at 17:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
> > Double ugh.  I guess we could get preprocess_function_rtes to
> > insert the appropriate relid ...
>
> OK, that was less painful than I feared.  makeWholeRowVar has
> several different special cases for RTE_FUNCTION, but most of them
> don't bear on this problem, because we wouldn't have applied inlining
> when they did.  It seems sufficient to fetch pg_type.typrelid for
> the function's nominal return type and store that if it's not 0.
>

Hmm, this introduces a new problem. Testing a case with a composite type:

create table foo (a int, b int);
insert into foo values (1,2);
create type t as (a int, b int);
create or replace function f() returns setof t as
  $$ select 1,2 from foo offset 0 $$ language sql stable;

then doing

update foo set b = f.b from f() where f.a = foo.a returning f;

or even just

select f from f();

triggers an Assert() in relation_open() from
get_relation_data_width(), from set_rel_width() because now that the
RTE has a relid, it attempts to open it, without having previously
locked it. Maybe we need to not clear rte->functions, and use that
instead.

Regards,
Dean

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Repair commits 317aba70e et al for -DWRITE_READ_PARSE_PLAN_TREES.

  2. Build whole-row Vars the same way during parsing and planning.

  3. Preserve RangeTblEntry.relid when expanding a view RTE.

  4. Fix incorrect non-strict join recheck in MERGE WHEN NOT MATCHED BY SOURCE.