Re: INSERT...ON DUPLICATE KEY IGNORE

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: INSERT...ON DUPLICATE KEY IGNORE
Дата
Msg-id 522491D7.2070705@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: INSERT...ON DUPLICATE KEY IGNORE  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: INSERT...ON DUPLICATE KEY IGNORE  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On 08/31/2013 06:40 AM, Josh Berkus wrote:
>> > 3) RETURNING is expanded - "RETURNING REJECTS *" is now possible where
>> > that makes sense.
> Oh, nifty!  OK, now I can *really* use this feature.

Absolutely; especially combined with COPY to a staging TEMPORARY or
UNLOGGED table.

It'll be yet another way for people to get upsert wrong, of course.
They'll use a wCTE with RETURNING REJECTS to do an UPDATE of the rejects
w/o locking the table against writes first. Documenting this pitfall
should be enough, though.

Speaking of upsert, I'm starting to think that to solve the upsert
problem without forcing full-table locking on people we need a lock type
that conflicts only with DELETE/INSERT and a way to prevent UPDATEs from
changing the key. Kind of like the table level inverse of FOR KEY UPDATE
- a way to say "you can change rows, just cannot add or remove from the
set of keys".

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Extension Templates S03E11
Следующее
От: Josh Berkus
Дата:
Сообщение: Next CFM?