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
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 |