From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: MERGE Specification |
Date: | 2008-04-22 01:28:30 |
Message-ID: | 1208827710.4259.979.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2008-04-21 at 20:28 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
> >> "MERGE will not invoke Rules." Does this imply that MERGE cannot be
> >> used on views or that the resulting INSERTs or UPDATEs do not work on
> >> views?
>
> > Yes, that's right. Just like COPY.
>
> I find this to be pretty ugly. COPY is a special case because
> (a) it is a utility statement not a plannable one, and (b) its only
> reason to exist is to transfer data as fast as possible, so bypassing
> rules isn't an unreasonable restriction. MERGE has neither of those
> properties, and thus arguing that it can or should be like COPY is an
> entirely unconvincing proposition.
Unrelated to rule processing, you did read the bit about MERGE and race
conditions? ISTM that MERGE as it stands isn't very useful for anything
other than large data loads since its going to cause problems if used
concurrently.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-04-22 01:57:20 | Re: MERGE Specification |
Previous Message | Simon Riggs | 2008-04-22 00:41:43 | Re: MERGE Specification |