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

From Robert Haas
Subject Re: logical changeset generation v6.4
Date
Msg-id CA+TgmoZRLm0E3EyQ3ou=-w9qPJtrPMpMMDXAzvMt3AmnAxV-Lg@mail.gmail.com
Whole thread Raw
In response to Re: logical changeset generation v6.4  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: logical changeset generation v6.4  (Merlin Moncure <mmoncure@gmail.com>)
Re: logical changeset generation v6.4  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Mon, Oct 14, 2013 at 9:12 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> Attached you can find version 6.4 of the patchset:

So I'm still unhappy with the arbitrary logic in what's now patch 1
for choosing the candidate key.  On another thread, someone mentioned
that they might want the entire old tuple, and that got me thinking:
there's no particular reason why the user has to want exactly the
columns that exist in some unique, immediate, non-partial index (what
a name).  So I have two proposals:

1. Instead of allowing the user to choose the index to be used, or
picking it for them, how about if we let them choose the old-tuple
columns they want logged?  This could be a per-column option.  If the
primary key can be assumed known and unchanging, then the answer might
be that the user wants *no* old-tuple columns logged.  Contrariwise
someone might want everything logged, or anything in the middle.

2. If that seems too complicated, how about just logging the whole old
tuple for version 1?

I'm basically fine with the rest of what's in the first two patches,
but we need to sort out some kind of consensus on this issue.

Thanks,

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



pgsql-hackers by date:

Previous
From: Cédric Villemain
Date:
Subject: Re: ERROR : 'tuple concurrently updated'
Next
From: Andreas Karlsson
Date:
Subject: Re: Adding new syntax in postgre sql