Re: logical changeset generation v3 - comparison to Postgres-R change set format

From: Noah Misch <noah(at)leadboat(dot)com>
To: Hannu Krosing <hannu(at)2ndQuadrant(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 00:28:51
Message-ID: 20130113002851.GD16171@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-01-13 00:47:18 Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Previous Message Bruce Momjian 2013-01-13 00:09:31 Latex longtable format