Re: MERGE Specification

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Decibel! <decibel(at)decibel(dot)org>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: MERGE Specification
Date: 2008-04-22 20:20:57
Message-ID: 20080422202057.GG9883@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 22, 2008 at 02:19:24PM -0500, Decibel! wrote:
> But no matter how this is done, I think we need to handle the race
> conditions, and handle them by default. If people *really* know what
> they're doing, they can disable the row locking (perhaps one way to
> do this would be to grab an explicit lock on the table and have merge
> check for that...).

I disagree. The spec doesn't require it and MERGE is useful without it.
For a first cut I would say implement as the spec says, race conditions
and all. Later we can think on whether it's worth handling them
directly.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message James Mansion 2008-04-22 20:33:58 Re: pgkill on win32
Previous Message Gurjeet Singh 2008-04-22 20:10:39 RECORD.* doesn't work in Pl/PGSQL