Re: MERGE vs REPLACE

Поиск
Список
Период
Сортировка
От Rick Gigger
Тема Re: MERGE vs REPLACE
Дата
Msg-id 65136D3A-E69D-4DAD-9D1A-DD75467D7048@alpinenetworking.com
обсуждение исходный текст
Ответ на Re: MERGE vs REPLACE  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
>> Conceptually, a MERGE statement is just a long string of INSERTs and
>> UPDATEs in the same transaction and I think we should treat it as
>> such.

I've just got one question about this.  Everyone seems to be saying  
that "try to insert and if that fails update" is the same as "try to  
insert and if that fails delete and then insert".

What about the following scenario:

mytable
------------
id  serial primary key,
a  int4,
b  int4,
data text

I've got an id field on every table because it simplifies a lot of  
things (such as slony configuration for example)
But I've also got a unique key on (a, b) and if I was to do a merge I  
would most likely do it in (a, b) not id.

If merge does a delete insert then it creates new values for the id  
columns which could cause me problems.  Basically any default fields  
are going to change or for that matter any fields not specified would  
be reinitialized whereas an update would leave them in place.

It seems to me that "try to update and if that fails insert" seems to  
be the best approach for not messing with existing data.  I guess   
"try to insert and if that fails update" gets you the same effect.

- Rick Gigger


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

Предыдущее
От: Dave Cramer
Дата:
Сообщение: PANIC: could not locate a valid checkpoint record
Следующее
От: daveg
Дата:
Сообщение: Re: MERGE vs REPLACE