Re: logical changeset generation v6.4

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(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:20:26
Message-ID: 20131021152026.GE2968@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-10-21 11:14:37 -0400, Robert Haas wrote:
> 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.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2013-10-21 15:26:47 Re: logical changeset generation v6.4
Previous Message Robert Haas 2013-10-21 15:18:07 Re: COPY table FROM STDIN doesn't show count tag