From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] MERGE SQL Statement for PG11 |
Date: | 2018-03-09 00:43:38 |
Message-ID: | CAH2-Wzn7mjBjrb7setGmjgOTNu57nET_k8nGZGUXqMBwEwGhww@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 8, 2018 at 3:29 PM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tsunakawa, Takayuki | 2018-03-09 00:50:03 | RE: Speed up the removal of WAL files |
Previous Message | Michael Paquier | 2018-03-09 00:23:21 | Re: Speed up the removal of WAL files |