Re: Re: [COMMITTERS] pgsql: Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Peter Geoghegan <pg(at)heroku(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
Date: 2015-05-21 12:42:17
Message-ID: 555DD2A9.202@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On 05/21/2015 05:08 AM, Peter Geoghegan wrote:
> On Wed, May 20, 2015 at 6:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I am not really sure that it was a good idea to invent
>> this command tag. In fact, I'm pretty sure it was a *bad* idea ---
>> what will happen if we ever create a statement actually named UPSERT?
>
> Why would we invent a statement actually named UPSERT?

And if we did, surely it would do some sort of an upsert operation, we
could use the UPSERT command tag for that too.

That said, I'm also not sure adding the UPSERT command tag is worth the
trouble. I'm OK with ripping it out. The row count returned in the
command tag is handy in the simple cases, but it gets complicated as
soon as you have rules or triggers, so you can't rely much on it anyway.
So as long as we document what the count means for an INSERT ... ON
CONFLICT, it should be OK to use the INSERT tag.

- Heikki

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2015-05-21 15:44:41 pgsql: Correct two mistakes in the ALTER FOREIGN TABLE reference page.
Previous Message Fujii Masao 2015-05-21 11:52:09 pgsql: Correct the names of pgstattuple_approx output columns in the do

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2015-05-21 12:42:26 pg_basebackup and replication slots
Previous Message Robert Haas 2015-05-21 12:38:33 Re: Parallel Seq Scan