On Thu, Mar 8, 2018 at 3:29 PM, Tomas Vondra
<tomas.vondra@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
