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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
