Ashutosh Bapat <ashutosh.ba...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers