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