Re: SQL:2011 application time

From: Zhihong Yu <zyu(at)yugabyte(dot)com>
To: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
Cc: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SQL:2011 application time
Date: 2021-09-06 20:40:13
Message-ID: CALNJ-vTS0=HW_N+On=jnD4n7raXpizSj7udJ14c13AVZNbXQTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 6, 2021 at 12:53 PM Paul A Jungwirth <
pj(at)illuminatedcomputing(dot)com> wrote:

> On Sat, Sep 4, 2021 at 12:56 PM Jaime Casanova
> <jcasanov(at)systemguards(dot)com(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2021-09-06 21:03:50 Re: Column Filtering in Logical Replication
Previous Message Paul A Jungwirth 2021-09-06 19:52:37 Re: SQL:2011 application time