Re: [HACKERS] MERGE SQL Statement for PG11
От | Peter Geoghegan |
---|---|
Тема | Re: [HACKERS] MERGE SQL Statement for PG11 |
Дата | |
Msg-id | CAH2-WzkaBK5SK51_yH-3tF_1B3uHuNLJ54JXRtrjYQLmp8qNfQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] MERGE SQL Statement for PG11 (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] MERGE SQL Statement for PG11
|
Список | pgsql-hackers |
On Mon, Mar 26, 2018 at 12:17 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >> As far as I >> know, the proposed MERGE patch has that issue an existing DML commands >> don't; but someone else may have better information. > > I will look deeper and report back. It's quite clear that the problem exists with the MERGE patch; the simple fact that RangeVarGetRelidExtended() is called twice with the same RangeVar argument shows this. However, the Oid cross-check seems like a sufficient defense against an inconsistency that causes real trouble, since the cross-check will only error-out when a concurrent table creation (or maybe ALTER TABLE) makes a second table visible, in a schema that appears earlier in the user's search_path. It's hard to imagine any legitimate user truly preferring some alternative behavior in this particular scenario, which makes it okay. This cross-check workaround is ugly, but apparently there is a precedent in copy.c. I didn't know that detail until Robert pointed it out. That makes me feel a lot better about this general question of how the target relation is represented, having two RTEs, etc. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: