Re: SQL:2011 application time

Поиск
Список
Период
Сортировка
От Zhihong Yu
Тема Re: SQL:2011 application time
Дата
Msg-id CALNJ-vTS0=HW_N+On=jnD4n7raXpizSj7udJ14c13AVZNbXQTw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: SQL:2011 application time  (Paul A Jungwirth <pj@illuminatedcomputing.com>)
Список pgsql-hackers


On Mon, Sep 6, 2021 at 12:53 PM Paul A Jungwirth <pj@illuminatedcomputing.com> wrote:
On Sat, Sep 4, 2021 at 12:56 PM Jaime Casanova
<jcasanov@systemguards.com.ec> wrote:
>
> patch 01: does apply but doesn't compile, attached the compile errors.
> patch 04: does not apply clean.

Thanks for taking a look! I've rebased & made it compile again. v7 attached.

Yours,
Paul
Hi,
For v7-0001-Add-PERIODs.patch :

+ * Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group

It seems the year (2018) should be updated to 2021.

For RemovePeriodById(), it seems table_open() can be called after SearchSysCache1(). This way, if HeapTupleIsValid(tup) is true, table_open() can be skipped.

For tablecmds.c, AT_PASS_ADD_PERIOD is defined as 5 with AT_PASS_ADD_CONSTR etc moved upward. Do we need to consider compatibility ?

There are a few TODO's such as:
+    * TODO: What about periods?

Are they going to be addressed in the next round of patches ?

There seems to be some overlap between ATExecAddPeriod() and AddRelationNewPeriod().
Is it possible to reduce code duplication ?

Cheers

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Paul A Jungwirth
Дата:
Сообщение: Re: SQL:2011 application time
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Column Filtering in Logical Replication