Re: logical changeset generation v6.4

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?

pg_dump support, psql completion, regression tests and minimal docs
included.

I am not 100% clear what the best way to handle
ALTER TABLE some_table REPLICA IDENTITY USING INDEX someindex;
DROP INDEX someindex;
is. Currently that's supposed to have the same effect as having
relreplident = 'd'.

Greetings,

Andres Freund

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