Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
> In ExecEvalConvertRowtype(), if the input row doesn't require any
> conversion, we simply return that row as is.
Huh. That's been like that for a very long time.
> I tried to create a testcase where this assertion would fail without
> multi-level partitioned table, but could not construct one.
You just need nested no-op ConvertRowtypeExprs, which is easily done with
multiple levels of inheritance:
regression=# create table pp (f1 int, f2 text);
CREATE TABLE
regression=# create table cc() inherits (pp);
CREATE TABLE
regression=# create table gc() inherits (cc);
CREATE TABLE
regression=# insert into gc values(11,'foo');
INSERT 0 1
regression=# select (gc.*)::cc from gc; gc
----------(11,foo)
(1 row)
regression=# select (gc.*)::cc::pp from gc;
server closed the connection unexpectedly
and in the log I've got
TRAP: FailedAssertion("!(( (tuple)->t_choice.t_datum.datum_typeid ) == indesc->tdtypeid || (
(tuple)->t_choice.t_datum.datum_typeid) == 2249)", File: "execExprInterp.c", Line: 2824)
Now the question is whether we should go to the trouble of making a tuple
copy just to inject the parent's rowtype. If the only reason to do so is
to satisfy ExecEvalConvertRowtype's own assertion, it seems like we might
be better advised just to drop the assertion. On the other hand it seems
like a good general principle that a tuple datum ought to be advertising
a rowtype OID that matches what the expression tree says it should be.
regards, tom lane
