On Mon, Oct 21, 2013 at 9:51 AM, Andres Freund <and...@2ndquadrant.com> wrote: > I have a hard time to understand why you dislike it so much. Think of a > big schema where you want to add auditing via changeset > extraction. Because of problems with reindexing primary key you've just > used candidate keys so far. Why should you go through each of a couple > of hundred tables and explictly choose an index when you just want an > identifier of changed rows? > By nature of it being a candidate key it is *guranteed* to uniquely > identify a row? And you can make the output plugin give you the used > columns/the indexname without a problem.
Sure, well, if a particular user wants to choose candidate keys essentially at random from among the unique indexes present, there's nothing to prevent them from writing a script to do that. But assuming that one unique index is just as good as another is just wrong. If you pick a "candidate key" that doesn't actually represent the users' notion of row identity, then your audit log will be thoroughly useless, even if it does uniquely identify the rows involved. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
