Re: logical changeset generation v3 - comparison to Postgres-R change set format
От | Noah Misch |
---|---|
Тема | Re: logical changeset generation v3 - comparison to Postgres-R change set format |
Дата | |
Msg-id | 20130113002851.GD16171@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: logical changeset generation v3 - comparison to Postgres-R change set format (Hannu Krosing <hannu@2ndQuadrant.com>) |
Ответы |
Re: logical changeset generation v3 - comparison to Postgres-R change
set format
Re: logical changeset generation v3 - comparison to Postgres-R change set format |
Список | 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.
В списке pgsql-hackers по дате отправления: