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
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 |
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 |