From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Tender Wang <tndrwang@gmail.com>
Cc: Duncan Sands <duncan.sands@deepbluecap.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Attribute of type record has wrong type error with MERGE ... WHEN NOT MATCHED BY SOURCE THEN DELETE
Date: Tue, 11 Mar 2025 16:06:04 -0400
Message-ID: <1638469.1741723564@sss.pgh.pa.us> (raw)
In-Reply-To: <CAEZATCVcQXJ3KQUZyN-2=jzk6U1rByJ74Xfq84zeCGXxPQjEsg@mail.gmail.com>
References: <3518c50a-ab18-482f-b916-a37263622501@deepbluecap.com>
<CAHewXNmuO70GHqZev500b9cGXRbHzU9cDsn2tMWqhv6bXWJ5qQ@mail.gmail.com>
<CAEZATCXguOaadS0LAkjo154RMru3zDS0ohCsE4r=z63tDhqb7Q@mail.gmail.com>
<971078.1741629162@sss.pgh.pa.us>
<1207317.1741633880@sss.pgh.pa.us>
<CAEZATCUQjxowkRfG89YOWStPvJ3xpJW9wDNccnZOVJzSAHwJxA@mail.gmail.com>
<1213530.1741637326@sss.pgh.pa.us>
<1620306.1741713271@sss.pgh.pa.us>
<CAEZATCVcQXJ3KQUZyN-2=jzk6U1rByJ74Xfq84zeCGXxPQjEsg@mail.gmail.com>
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> 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.
Geez, our regression tests seem quite lacking in this area.
I'm wondering why we're trying to do relation_open on a SUBQUERY
RTE, relid or no relid. It seems kind of accidental that
set_rel_width() doesn't fail on subqueries given this coding.
Even without actual failure, looking to the referenced relation for
width estimates for a subquery seems like a pretty broken idea.
However, this does indicate that putting a composite type's relid
into the RTE is more dangerous than I thought --- there may be
other code out there doing things similar to set_rel_width().
> Maybe we need to not clear rte->functions, and use that
> instead.
At first I didn't like that idea a bit, and it's still rather ugly,
but it does have two advantages:
* it seems less likely to break anyone's assumptions about the data
structure;
* we'd avoid a purely speculative catcache fetch in
preprocess_function_rtes, which most of the time is a waste of effort
because no subsequent makeWholeRowVar will happen.
We could still clear rte->functions during setrefs.c, so that this
abuse of the data structure is purely local to the planner.
I'll have a go at coding it that way...
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, dean.a.rasheed@gmail.com, tndrwang@gmail.com, duncan.sands@deepbluecap.com, pgsql-bugs@lists.postgresql.org
Subject: Re: Attribute of type record has wrong type error with MERGE ... WHEN NOT MATCHED BY SOURCE THEN DELETE
In-Reply-To: <1638469.1741723564@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox