Andrew Dunstan <and...@dunslane.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers