Re: auto_explain causes regression failures

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I am getting regression failures on the rowtypes, transactions and
> arrays tests. Diff file is attached. I'm going to look into it, but if
> anyone has a good idea what's going on please speak up ASAP.

Hmm. Didn't decipher the transactions-test failures yet, but the
errors about "unexpected refassgnexpr" and "unexpected FieldStore"
are a pre-existing bug that you can expose without auto_explain:

regression=# explain verbose INSERT INTO arrtest (a[1:5], b[1:1][1:2][1:2], c, d, f, g)
VALUES ('{1,2,3,4,5}', '{{{0,0},{1,2}}}', '{}', '{}', '{}', '{}');
ERROR: unexpected refassgnexpr

The problem is that get_rule_expr() expects any top-level assignment
nodes to have been stripped off by processIndirection(), and explain.c
is failing to cater to that. It's not just a simple oversight ---
it's not exactly clear how such an expr tree should be printed without
any context. Normally, we're decoding such things in the context
of reverse-listing a whole INSERT or UPDATE statement, and the upper
level ruleutils.c code takes care of putting the indirection annotation
on the target column name. But for EXPLAIN we're just trying to treat
the plan target list as a list of standalone expressions. What should
the display look like?

If you're lost about the point here, it's this: an ArrayExpr can
represent the result of an array assignment. For example, given
UPDATE foo SET a[42] = x, what is generated is an ArrayExpr
with refexpr = a, refupperindexpr = 42, refassgnexpr = x.
On execution that generates the updated array value that needs to
get stored back into the "a" column. How would you like to print
that in EXPLAIN? Same deal for FieldStore: it can represent generating
the new value of a composite column after replacing one field.

regards, tom lane