From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, David Fetter <david(at)fetter(dot)org>, chris <cbbrowne(at)ca(dot)afilias(dot)info>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Postgres-R: primary key patches |
Date: | 2008-07-18 17:12:42 |
Message-ID: | 4880CF0A.4010709@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Alvaro Herrera wrote:
> I think the point here is that you need to distinguish which tuple you
> need to update. For this, our Replicator uses the primary key only;
> there's no way to use another candidate key (unique not null). It would
> certainly be possible to use a different candidate key,
Yeah, and for this to work, the *sender* needs to decide on a key to use.
> but as far as I
> know no customer has ever requested this.
I can't see the use case for a separate REPLICATION KEY, different from
the PRIMARY KEY, either..
> (FWIW we don't send the old values -- only the original PK columns, the
> values of columns that changed, and the "update mask" in terms of
> heap_modify_tuple.)
Yup, that's pretty much the same what I'm doing for Postgres-R.
Regards
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-07-18 17:16:12 | Re: typedefs for indent |
Previous Message | David E. Wheeler | 2008-07-18 16:53:31 | Re: PATCH: CITEXT 2.0 v4 |