On Mon, Oct 21, 2013 at 9:51 AM, Andres Freund <andres@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
