On Thu, Apr 6, 2017 at 8:51 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> 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);
> regression=# create table cc() inherits (pp);
> regression=# create table gc() inherits (cc);
> 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

Oh, I tried multi-level inheritance, but always tried to select on the
topmost parent. Obviously that didn't work since we flatten
inheritance in planner. I tried to cast rows of one table to the type
of another table with the same definition. We don't allow such
coercion. I missed
    if (typeInheritsFrom(inputTypeId, targetTypeId)
        || typeIsOfTypedTable(inputTypeId, targetTypeId))
in coerce_type().

> 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.

Yes, I too came to the same conclusion.

Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to