Re: logical changeset generation v6.4 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: logical changeset generation v6.4
Date
Msg-id 20131025145815.GD5627@awork2.anarazel.de
Whole thread Raw
In response to Re: logical changeset generation v6.4  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: logical changeset generation v6.4  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On 2013-10-22 16:07:16 +0200, Andres Freund wrote:
> On 2013-10-21 20:16:29 +0200, Andres Freund wrote:
> > 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.

So, I am currently wondering about how to store the "old" tuple, based
on this. Currently it is stored using the TupleDesc of the index the old
tuple is based on. But if we want to allow transporting the entire tuple
that obviously cannot be the only option.
One option would be to change the stored format based on what's
configured, using the relation's TupleDesc if FULL is used. But I think
always using the heap relation's desc is better.
The not-logged columns would then just be represented as NULLs. That
will make old primary keys bigger if the relation has a high number of
columns and the key small, but I don't think it matters enough.

Opinions?

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Detection of nested function calls
Next
From: Tom Lane
Date:
Subject: Re: Detection of nested function calls