Re: logical changeset generation v6.4

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: logical changeset generation v6.4
Date: 2013-10-18 12:11:29
Message-ID: CA+TgmoZRLm0E3EyQ3ou=-w9qPJtrPMpMMDXAzvMt3AmnAxV-Lg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 14, 2013 at 9:12 AM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2013-10-18 12:21:33 Re: Adding new syntax in postgre sql
Previous Message Cédric Villemain 2013-10-18 11:41:28 Re: ERROR : 'tuple concurrently updated'