> Something that a in-core method might be able to do that an external one > can't would be to support a method of uniquely identifying rows in > tables with no PK's. A gross example (that undoubtedly wouldn't work in > the real world) would be using TID's. A real-world implementation might > be based on a hidden serial column.
Realistically you need more than a serial for MM replication. For each row-version, you need: serverID of last update serialID of row timestamp of last update ... and note that this would have to include deleted rows as well. Currently Bucardo does this by using several fields, but you could put together one 128-bit field which contains all of this information. Or you could do an Intagram and compress it into 64 bits, but that would require limiting the problem space in a way you probably can't do it for a general tool. I do agree that depending on user-defined PKs raises a whole host of issues which we'd rather just sidestep, though. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
