On 05/06/2015 10:47 PM, Peter Geoghegan wrote:
On Wed, May 6, 2015 at 8:20 AM, Andres Freund <and...@anarazel.de> wrote:
On 2015-05-05 15:00:56 -0700, Peter Geoghegan wrote:
Locking the row is not "nothing", though. If you want to lock the row,
use an UPSERT with a tautologically false WHERE clause (like "WHERE
false").
That's not the same. For one it "breaks" RETURNING which is a death
knell, for another it's not exactly obvious.
DO NOTHING already doesn't project non-inserted tuples, in a way that
fits with the way we won't do that when a before trigger returns NULL.
So I don't know what you mean about RETURNING behavior.
It may not be all that obvious, but then the requirement that you
mention isn't either. I really strongly feel that DO NOTHING should do
nothing. For the pgloader use-case, which is what I have in mind with
that variant, that could literally make the difference between
dirtying an enormous number of buffers and dirtying only a few. This
will *frequently* be the case. And it's not as if the idea of an
INSERT IGNORE is new or in any way novel. As I mentioned, many systems
have a comparable command.
So, yes, DO NOTHING does very little - and that is its appeal.
Supporting this behavior does not short change those who actually care
about the existing tuple sticking around for the duration of their
transaction - they have a way of doing that. If you want to document
INSERT IGNORE as being primarily an ETL-orientated thing, that would
make sense, but let's not hobble that use case.
Yeah, I agree that DO NOTHING should not lock the rows. It might make
sense to have a DO LOCK variant, which locks the rows, although I don't
immediately see what the use case would be.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
