From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: logical changeset generation v6.4 |
Date: | 2013-10-21 15:14:37 |
Message-ID: | CA+Tgmoa8z+yCjsJMea3LCMXgPd1R=jyXmLrew1bUvH+7EoONKg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 21, 2013 at 9:51 AM, Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-10-21 15:18:07 | Re: COPY table FROM STDIN doesn't show count tag |
Previous Message | Mike Blackwell | 2013-10-21 15:13:54 | Re: Commitfest II CLosed |