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
