Re: logical changeset generation v6.4

On Tue, Oct 22, 2013 at 10:07 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-10-21 20:16:29 +0200, Andres Freund wrote:
>> On 2013-10-18 20:50:58 +0200, Andres Freund 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)
>>
>> Current draft is:
>> ALTER TABLE ... REPLICA IDENTITY NOTHING|FULL|DEFAULT
>> ALTER TABLE ... REPLICA IDENTITY USING INDEX ...;
>>
>> which leaves the door open for
>>
>> ALTER TABLE ... REPLICA IDENTITY USING '(' column_name_list ')';
>>
>> Does anybody have a strong feeling about requiring support for CREATE
>> TABLE for this?
>
> Attached is a patch ontop of master implementing this syntax. It's not
> wired up to the changeset extraction patch yet as I am not sure whether
> others agree about the storage.
>
> pg_class grew a 'relreplident' char, storing:
> * 'd' default
> * 'n' nothing
> * 'f' full
> * 'i' index with indisreplident set, or default if index has been
> dropped
> pg_index grew a 'indisreplident' bool indicating it is set as the
> replica identity for a replident = 'i' relation.
>
> Both changes shouldn't change the width of the affected relations, they
> should reuse existing padding.
>
> Does somebody prefer a different storage?

I had imagined that the storage might consist simply of a pg_attribute
boolean. So full would turn them all on, null would turn them all of,
etc. But that does make it hard to implement the "whatever the pkey
happens to be right now" behavior, so maybe your idea is better.

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