Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Дата
Msg-id CAM3SWZTxd45WdJrSH7b9XyV1jMMS7fKKP1Nu6aARttE8v7h+tw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: exitArchiveRecovery woes
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Proposal: Log inability to lock pages during vacuum