On Thu, Dec 18, 2014 at 9:31 AM, Peter Geoghegan <p...@heroku.com> wrote: >> So I think there needs to be some kind of logic to de-recognize the table >> alias "foo". >> >> Once I rewrote the query to use TARGET and EXCLUDED correctly, I've put this >> through an adaptation of my usual torture test, and it ran fine until >> wraparound shutdown. I'll poke at it more later. > > Oops. I agree with your diagnosis, and will circle around to fix that > bug in the next revision
Attached patch fixes the bug. I'm not delighted about the idea of cutting off parent parse state (the parse state of the insert) within transformUpdateStmt() only once we've used the parent state to establish that this is a "speculative"/auxiliary update, but it's probably the path of least resistance here. When this is rolled into the next version, there will be a testcase. Thanks -- Peter Geoghegan
diff --git a/src/backend/parser/analyze.c b/src/backend/parser/analyze.c index e037c0f..8c25e82 100644 --- a/src/backend/parser/analyze.c +++ b/src/backend/parser/analyze.c @@ -2006,6 +2006,16 @@ transformUpdateStmt(ParseState *pstate, UpdateStmt *stmt) qry->hasModifyingCTE = pstate->p_hasModifyingCTE; } + /* + * Having established that this is a speculative insertion's auxiliary + * update, do not allow the query to access parent parse state. This is a + * simple way of making parent RTEs invisible -- otherwise, the parent's + * target could spuriously become visible were the query to reference the + * original target table name rather than the TARGET.* alias. + */ + if (pstate->p_is_speculative) + pstate->parentParseState = NULL; + qry->resultRelation = setTargetTable(pstate, stmt->relation, interpretInhOption(stmt->relation->inhOpt), true,
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
