From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Best practices: MERGE |
Date: | 2005-03-08 08:32:57 |
Message-ID: | 422D6339.8010502@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
> You can create a procedure to do that, but MERGE would work better.
>
> ISTM that would require writing some new code that was a mix of
> heap_update and heap_insert logic for the low level stuff would be
> required. The existing heap_update code is most similar, since the logic
> is roughly
>
> UPDATE WHERE.... (locate row)
> IF FOUND THEN
> INSERT (new row version)
>
> though with various changes to row visibility stuff.
>
> One might aim to do this in two stages:
> 1. initially support a single row upsert such as MySQL's REPLACE command
> 2. a full implementation of MERGE that used set logic as per the spec
>
> ...
The main issue is dealing with merging into unique index race conditions.
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2005-03-08 09:18:36 | Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables for |
Previous Message | Simon Riggs | 2005-03-08 08:31:35 | Re: Cost of XLogInsert CRC calculations |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2005-03-08 09:18:36 | Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables for |
Previous Message | Simon Riggs | 2005-03-08 08:28:06 | Re: Best practices: MERGE |