Re: logical changeset generation v6.4

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: logical changeset generation v6.4
Дата
Msg-id CA+TgmoZRLm0E3EyQ3ou=-w9qPJtrPMpMMDXAzvMt3AmnAxV-Lg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: logical changeset generation v6.4  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: logical changeset generation v6.4  (Merlin Moncure <mmoncure@gmail.com>)
Re: logical changeset generation v6.4  (Andres Freund <andres@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Cédric Villemain
Дата:
Сообщение: Re: ERROR : 'tuple concurrently updated'
Следующее
От: Andreas Karlsson
Дата:
Сообщение: Re: Adding new syntax in postgre sql