Re: [HACKERS] MERGE SQL Statement for PG11 - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: [HACKERS] MERGE SQL Statement for PG11
Date
Msg-id CAH2-WzmnQ81DGDdjD=F1zV_2aS+9oTnM489nzsFJSQu+9nOTCg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] MERGE SQL Statement for PG11  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] MERGE SQL Statement for PG11  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On Thu, Mar 8, 2018 at 6:52 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I removed this code since it was wrong. We might want to add some basic
>> checks for existence of volatile functions in the WHEN or SET clauses. But I
>> agree, it's no different than regular UPDATEs. So may be not a big deal.
>
> I just caught up on this thread.  I'm definitely glad to see that code
> go because, wow, that is all kinds of wrong.  I don't see a real need
> to add any kind of replacement check, either.  Prohibiting volatile
> functions here doesn't seem likely to accomplish anything useful.  It
> seems like the most we'd want to do is mention this the documentation
> somehow, and I'm not even sure we really need to do that much.

Thanks in large part to Pavan's excellent work, the situation in
nodeModifyTable.c is much clearer than it was a few weeks ago. It's
now obvious that MERGE is very similar to UPDATE ... FROM, which
doesn't have any restrictions on volatile functions.

I don't see any sense in prohibiting volatile functions in either
case, because it should be obvious to users that that's just asking
for trouble. I can believe that someone would make that mistake, just
about, but they'd have to be writing their DML statement on
auto-pilot.

-- 
Peter Geoghegan


pgsql-hackers by date:

Previous
From: Jeremy Finzel
Date:
Subject: using worker_spi as pattern
Next
From: Tom Lane
Date:
Subject: Re: Testbed for predtest.c ... and some arguable bugs therein