Hi all I'm finding it necessary to remap the varno and varattno of Var elements in RETURNING lists as part of updatable s.b. view processing. A reference to a view col in RETURNING must be rewritten to point to the new resultRelation at the top level, so that the effects of BEFORE triggers are visible in the returned result.
Usually the view will have a different structure to the base table, and in this case it's necessary to change the varattno of the Var to point to the corresponding col on the base rel. So the short version: Given the RTE for a simple view with only one base rel and an attribute number for a col in that view, and assuming that the view col is a simple reference to a col in the underlying base rel, is there any sane way to get the attribute number for the corresponding col on the base rel? For example, given: CREATE TABLE t (a integer, b text, c numeric); CREATE VIEW v1 AS SELECT c, a FROM t; UPDATE v1 SET c = NUMERIC '42' RETURNING a, c; ... the Vars for a and c in the RETURNING clause need to be remapped so their varno is the rti for t once the RTE has been injected, and the varattnos need changing to the corresponding attribute numbers on the base table. So a Var for v1(c), say (1,1), must be remapped to (2,3) i.e. varno 2 (t), varattno 3 (c). I'm aware that this is somewhat like the var/attr twiddling being complained about in the RLS patch. I don't see a way around it, though. I can't push the RETURNING tlist entries down into the expanded view's subquery and add an outer Var reference - they must point directly to the resultRelation so that we see the effects of any BEFORE triggers. I'm looking for advice on how to determine, given an RTI and an attribute number for a simple view, what the attribute number of the col in the view's base relation is. It can be assumed for this purpose that the view attribute is a simple Var (otherwise we'll ERROR out, since we can't update an expression). I'm a bit stumped at this point. I could adapt the ChangeVarNodes walker to handle the actual recursive rewriting and Var changing. It assumes that the varattno is the same on both the old and new varno, as it's intended for when you have an RT index change, but could be taught to optionally remap varattnos. To do that, though, I need a way to actually do that varattno remapping cleanly. Anyone got any ideas? -- Craig Ringer -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers