| From: | Anssi Kääriäinen <anssi(dot)kaariainen(at)thl(dot)fi> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, "Kevin Grittner" <kgrittn(at)ymail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
| Date: | 2014-12-05 06:27:15 |
| Message-ID: | 1417760835.22478.80.camel@TTY32 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2014-12-04 at 10:27 -0800, Peter Geoghegan wrote:
> I think that the standard for adding a new system attribute ought to
> be enormous. The only case where a new one was added post-Postgres95
> was "tableoid". I'm pretty sure that others aren't going to want to do
> it that way. Besides, I'm not entirely convinced that this is actually
> an important distinction to expose.
For Django's use case this is a requirement. We must inform the user if
the save() action created a new row or if it modified an existing one.
Another way to do this would be to expose the "excluded" alias in the
returning clause. All columns of the excluded alias would be null in
the case of insert (especially the primary key column), and thus if a
query
insert into foobar values(2, '2') on conflict (id) update set other_col=excluded.other_col returning excluded.id
returns a non-null value, then it was an update.
- Anssi
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2014-12-05 06:37:00 | Re: On partitioning |
| Previous Message | Adam Brightwell | 2014-12-05 05:29:57 | check-world failure: dummy_seclabel |