Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Date
Msg-id CAM3SWZTxd45WdJrSH7b9XyV1jMMS7fKKP1Nu6aARttE8v7h+tw@mail.gmail.com
Whole thread Raw
In response to Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On Thu, Dec 18, 2014 at 9:20 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> After actually reading the documentation more closely, I decided this should
> be an error because "foo" is not a valid table alias in the "update set"
> expression.  Instead of being a parsing/planning error, this executes and
> the foo.count on the RHS of the assignment always evaluates as zero (even on
> subsequent invocations when TARGET.count is 1).
>
> If I switch to a text type, then I get seg faults under the same condition:

> So I think there needs to be some kind of logic to de-recognize the table
> alias "foo".
>
> Once I rewrote the query to use TARGET and EXCLUDED correctly, I've put this
> through an adaptation of my usual torture test, and it ran fine until
> wraparound shutdown.  I'll poke at it more later.

Oops. I agree with your diagnosis, and will circle around to fix that
bug in the next revision by, as you say, simply rejecting the query if
it doesn't use the two standard aliases.

Thanks for testing!
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: exitArchiveRecovery woes
Next
From: Jim Nasby
Date:
Subject: Re: Proposal: Log inability to lock pages during vacuum