On 2013-10-21 11:14:37 -0400, Robert Haas wrote: > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
