On 2013-10-21 11:14:37 -0400, Robert Haas wrote:
> 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.
Why? If the columns are specified in the log, by definition the values
will be sufficient to identify a row. Even if a "nicer" key might exist.
Since I seemingly can't convince you, I'll modify things that way for
now as it can easily be changed later, but I still don't see the
problem.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
