Re: logical changeset generation v6.4

On 2013-10-21 09:40:13 -0400, Robert Haas wrote:
> On Fri, Oct 18, 2013 at 2:50 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > How about modifying the selection to go from:
> > * all rows if ALTER TABLE ... REPLICA IDENTITY NOTHING|FULL;
> > * index chosen by ALTER TABLE ... REPLICA IDENTITY USING indexname
> > * [later, maybe] ALTER TABLE ... REPLICA IDENTITY (cola, colb)
> > * primary key
> > * candidate key with the smallest oid
> >
> > Including the candidate key will help people using changeset extration
> > for auditing that do not have primary key. That really isn't an
> > infrequent usecase.
> >
> > I've chosen REPLICA IDENTITY; NOTHIN; FULL; because those are all
> > existing keywords, and afaics shouldn't generate any conflicts. On a
> > green field we probably name them differently, but ...
>
> I'm really pretty much dead set against the "candidate key with the
> smallest OID" proposal. I think that's just plain old bad idea. It's
> just magical behavior which will result in users being surprised and
> unhappy. I don't think there's really a problem with saying, hey, if
> you configure changeset extraction and you don't configure a replica
> identity, then you don't get any columns from the old tuple.

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.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services