Re: MERGE Specification

From: Hannes Dorbath <light(at)theendofthetunnel(dot)de>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: MERGE Specification
Date: 2008-04-26 09:01:02
Message-ID: 4812EF4E.9010707@theendofthetunnel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> On Fri, 2008-04-25 at 10:03 +0300, Hannu Krosing wrote:
>> On Tue, 2008-04-22 at 00:24 +0100, Simon Riggs wrote:
>>> 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. That seems fine to me because you're
>>> likely to be doing a MERGE immediately after a COPY anyway, so the
>>> restriction just continues.
>> May be the bulk data merging variant of MERGE to be used after initial
>> COPY should be a variant of COPY with special keyword(s) instead of
>> MERGE ?
>
> That does sound like a good way of differentiating between the OLTP and
> bulk loading cases.
>
> I'll bear that in mind as we develop.

To me, a simple user, it'd be important that MERGE implementation does
not place any unpredictable restrictions. For example in Oracle you can
break any MERGE statement by placing a full text index on the table. So
I'd really expect a MERGE in PostgreSQL to be fine with views, rules,
tsearch, etc.

Just my 2 cent.

--
Best regards,
Hannes Dorbath

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2008-04-26 13:10:53 Re: Re: [HACKERS] [COMMITTERS] pgsql: Fix TransactionIdIsCurrentTransactionId() to use binary search
Previous Message Bryce Nesbitt 2008-04-26 07:08:44 Re: Tech details - psql wraps at window width