On Thu, Mar 22, 2018 at 7:13 PM, Peter Geoghegan <p...@bowt.ie> wrote: > While I think this this particular HINT buglet is pretty harmless, I > continue to be concerned about the unintended consequences of having > multiple RTEs for MERGE's target table. Each RTE comes from a > different lookup path -- the first one goes through setTargetTable()'s > parserOpenTable() + addRangeTableEntryForRelation() calls. The second > one goes through transformFromClauseItem(), for the join, which > ultimately ends up calling transformTableEntry()/addRangeTableEntry(). > Consider commit 5f173040, which fixed a privilege escalation security > bug around multiple name lookup. Could the approach taken by MERGE > here introduce a similar security issue?
Yeah, that seems really bad. I don't think there is a huge problem with having multiple RTEs; for example, we very commonly end up with both rte->inh and !rte->inh RTEs for the same table, and that is OK. However, generating those RTEs by doing multiple name lookups for the same table is a big problem. Imagine, for example, that a user has a search_path of a, b and that there is a table b.foo. The user does a merge on foo. Between the first name lookup and the second, somebody creates a.foo. Now, potentially, half of the MERGE statement is going to be running against b.foo and the other half against a.foo. I don't know whether that will crash or bomb out with a strange error or just make some unexpected modification to one of those tables, but the behavior, even if not insecure, will certainly be wrong. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company