Re: Best practices: MERGE

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

In response to

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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