Re: logical changeset generation v6.4

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. If you
don't like that, change the configuration. It's always nice to spare
users unnecessary configuration, of course, but trying to make things
simpler than they really are tends to hurt more than it helps.

On the naming, I find REPLICA IDENTITY to be pretty good. We've
already places where we're using the REPLICA keyword to indicate
places where we've got core support intended to dovetail with external
replication solutions, and this seems to fit that paradigm nicely.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company