On Thu, Mar 8, 2018 at 3:29 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > The reason why the patch tried to prevent that is because the SQL > standard says this (p. 1176 of SQL 2016): > > 15) The <search condition> immediately contained in a <merge statement>, > the <search condition> immediately contained in a <merge when matched > clause>, and the <search condition> immediately contained in a <merge > when not matched clause> shall not generally contain a <routine > invocation> whose subject routine is an SQL-invoked routine that > possibly modifies SQL-data. > > I'm not quite sure what is required to be compliant with this rule. For > example what does "immediately contained" or "shall not generally > contain" mean? Does that mean user are expected not to do that because > it's obviously silly, or do we need to implement some protection?
My impression is that this means that you shouldn't treat this as a particularly likely case, or try to facilitate it. The <search condition> blurb is about intent, rather than actual restrictions implementations must enforce, AFAICT. Though the UPDATE precedent is what really matters here -- not the SQL standard. The SQL standard doesn't say anything to make me doubt that that's the right precedent to want to follow. Close by, under "General Rules", rule #4 is: "The extent to which an SQL-implementation may disallow independent changes that are not significant is implementation-defined". This same sentence appears in quite a few different places, including in the description of UPDATE. ISTM that the SQL standard actually enforces that volatile qual weirdness (and what to do about it) is a general INSERT/UPDATE/DELETE/MERGE issue. > That being said the volatility check seems reasonable to me (and i would > not expect it to be a huge amount of code). If we're going to do this, we'd have to do the same with UPDATE, IMV. And, well, we're not gonna do that. -- Peter Geoghegan
