On Thu, Nov 02, 2017 at 03:25:48PM -0700, Peter Geoghegan wrote:
> Nico Williams <nico@cryptonector.com> wrote:
> >A MERGE mapped to a DML like this:
>
> This is a bad idea. An implementation like this is not at all
> maintainable.
Assuming the DELETE issue can be addressed, why would this not be
maintainable?
> >can handle concurrency via ON CONFLICT DO NOTHING in the INSERT CTE.
>
> That's not handling concurrency -- it's silently ignoring an error. Who
> is to say that the conflict that IGNORE ignored is associated with a row
> visible to the MVCC snapshot of the statement? IOW, why should the DELETE
> affect any row?
Ah, yes, we'd have to make sure the DELETE does not delete rows that
could not be inserted. There's... no way to find out what those would
have been -- RETURNING won't mention them, though it'd be a nice
addition to UPSERT to have a way to do that, and it'd make this mapping
feasible.
> There are probably a great many reasons why you need a ModifyTable
> executor node that keeps around state, and explicitly indicates that a
> MERGE is a MERGE. For example, we'll probably want statement level
> triggers to execute in a fixed order, regardless of the MERGE, RLS will
> probably require explicitly knowledge of MERGE semantics, and so on.
Wouldn't those fire anyways in a statement like the one I mentioned?
> FWIW, your example doesn't actually have a source (just a target), so it
> isn't actually like MERGE.
That can be added. I was trying to keep it pithy.
Nico
--
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers