On Sun, Jun 18, 2017 at 9:21 PM, Peter Geoghegan wrote:
> Returning rows with duplicate values seems rather unorthodox.
>
Ok, then option 2 it is.
In summary, this is what I am going to (attempt to) implement for the new
syntax:
INSERT ...
ON CONFLICT (...) DO SELECT
RETURNING ...
1. Rows
On Sun, Jun 18, 2017 at 4:33 AM, Matt Pulver wrote:
> This would be nearly identical to the existing error message that is
> produced when running:
>
> INSERT INTO example (name) VALUES ('foo'), ('foo')
> ON CONFLICT (name) DO UPDATE SET value=1
> RETURNING *
>
>
> which gives the error message:
>
On Sat, Jun 17, 2017 at 9:55 PM, Peter Geoghegan wrote:
> On Sat, Jun 17, 2017 at 7:49 AM, Matt Pulver
> wrote:
> > With the proposed "INSERT ... ON CONFLICT () SELECT" feature, the
> > get_or_create_id() function is simplified to:
>
> Are you locking the existing rows? Because otherwise, the
>
On Sat, Jun 17, 2017 at 7:49 AM, Matt Pulver wrote:
> With the proposed "INSERT ... ON CONFLICT () SELECT" feature, the
> get_or_create_id() function is simplified to:
Are you locking the existing rows? Because otherwise, the
determination that they're conflicting can become obsolete immediately
Hello,
I am looking to add a new language feature that returns the rows that
conflict on an INSERT, and would appreciate feedback and guidance on this.
Here is an example.
To implement a get_or_create_id() function, this is how it must currently
be done:
CREATE TABLE example (
id SERIAL PRI
