From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Markus Wanner <markus(at)bluegap(dot)ch>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: logical changeset generation v3 - comparison to Postgres-R change set format |
Date: | 2013-01-13 20:46:54 |
Message-ID: | 50F31D3E.2060503@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/13/2013 12:28 AM, Noah Misch wrote:
> [Catching up on old threads.]
>
> On Sat, Nov 17, 2012 at 03:40:49PM +0100, Hannu Krosing wrote:
>> On 11/17/2012 03:00 PM, Markus Wanner wrote:
>>> On 11/17/2012 02:30 PM, Hannu Krosing wrote:
>>>> Is it possible to replicate UPDATEs and DELETEs without a primary key in
>>>> PostgreSQL-R
>>> No. There must be some way to logically identify the tuple.
>> It can be done as selecting on _all_ attributes and updating/deleting
>> just the first matching row
>>
>> create cursor ...
>> select from t ... where t.* = (....)
>> fetch one ...
>> delete where current of ...
>>
>> This is on distant (round 3 or 4) roadmap for this work, just was
>> interested
>> if you had found any better way of doing this :)
> That only works if every attribute's type has a notion of equality ("xml" does
> not). The equality operator may have a name other than "=", and an operator
> named "=" may exist with semantics other than equality ("box" is affected).
> Code attempting this replication strategy should select an equality operator
> the way typcache.c does so.
A method for making this work as PostgreSQL works now would be to
compare "textual representations" of tuples
create cursor ...
select from t ... where t::text = '(<image of original row>)'
fetch one ...
delete where current of ...
But of course having an operator for "sameness" without needing to convert to text
would be better
----------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2013-01-13 20:50:06 | Re: erroneous restore into pg_catalog schema |
Previous Message | Tom Lane | 2013-01-13 20:44:58 | Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4) |