public inbox for [email protected]
help / color / mirror / Atom feedFrom: Chao Li <[email protected]>
To: jian he <[email protected]>
To: Ayush Tiwari <[email protected]>
Cc: Zsolt Parragi <[email protected]>
Cc: [email protected]
Cc: Peter Eisentraut <[email protected]>
Subject: Re: [PATCH] Rebuild CHECK constraints after generated column SET EXPRESSION
Date: Wed, 10 Jun 2026 17:15:38 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CACJufxFG+vn8vdHAedGuqwb9iC58HHPGSEaLwm6_Tcv-3AyH=w@mail.gmail.com>
References: <CAJTYsWXOkyeDVbzymWc9sKrq7Y_MUv6XJXN4H9GfsBOPd3NJ+w@mail.gmail.com>
<CACJufxE3e1jPsKLsjNWMucahFJW7UO_UGWzhRESRvJ+8PeKgkg@mail.gmail.com>
<CAJTYsWX+g49jMArk0MdS0+suEY8CckyAYpm+KvNLU9Zx9=6t3g@mail.gmail.com>
<CACJufxGPNgAcQEiwD0QFCTP8vi0XZzys06EEQUnR84_0Qo9s9Q@mail.gmail.com>
<CAJTYsWUooEDFaNOiOLjz0NqmqBtof65b-sQQHWmh8jV9t-VYEA@mail.gmail.com>
<CACJufxGBSeAcyStRHajNvqerGCRGB5Wb=e5cbGd7HFT4=aMsLw@mail.gmail.com>
<CAJTYsWWw7s0N2hnAW9pfhkSx-aN=wELErrBEicoPMnmmS1e7kg@mail.gmail.com>
<CACJufxGdr-A7hwBRWh02YHbb13M-LG3bAOad+86iivp2008tTA@mail.gmail.com>
<CAN4CZFMHmb=o_GkJrgEY1iEQpnuDtL_YEHKFZNWG0bdZyozXvA@mail.gmail.com>
<CACJufxFG+vn8vdHAedGuqwb9iC58HHPGSEaLwm6_Tcv-3AyH=w@mail.gmail.com>
> On Jun 2, 2026, at 08:41, jian he <[email protected]> wrote:
>
> On Fri, May 29, 2026 at 6:58 AM Zsolt Parragi <[email protected]> wrote:
>>
>> Looks good, I have one nitpick question:
>>
>> + if (isnull)
>> + elog(WARNING, "null conbin for relation \"%s\"",
>> + RelationGetRelationName(rel));
>>
>> Shouldn't this be an error instead? Most existing checks treat it as
>> an error, and that seems better to me as this shouldn't happen
>> normally?
>>
> OK.
>
> I changed it to:
>> + if (isnull)
>> + elog(ERROR, "null conbin for relation \"%s\"",
>> + RelationGetRelationName(rel));
>
> I also slightly rephrased the commit message.
>
>
>
> --
> jian
> https://www.enterprisedb.com/
Sorry for not noticing this thread earlier. I also found the same problem while testing the feature and posted a patch in [1]. Thanks to Jian for pointing out this thread.
After reading v6 from this thread, I think my implementation is slightly different:
* v6 adds a new helper, RememberWholeRowDependentForRebuilding(), which reads pg_constraint and pg_index to find objects to rebuild.
* My implementation in [1] reuses RememberAllDependentForRebuilding(), which reads pg_depend, because whole-row dependencies have refobjsubid = 0. My v1 missed the partial-index case, so I added a new helper in v2 to read pg_index.
The main difference is that my patch reuses the existing dependency-based rebuild machinery where possible, and only scans pg_index directly for the partial-index case where pg_depend does not record the whole-row Var dependency. It is also smaller: this thread’s v6 adds 185 lines to tablecmds.c, while my v2 adds 123 lines.
Would you mind taking a look at my implementation in [1]?
BTW, I have also added this problem to the open items list, as I think it should be fixed before releasing v19.
[1] https://www.postgresql.org/message-id/71242FEA-15A3-4073-9FA1-561CA744ACBD%40gmail.com
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
view thread (6+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PATCH] Rebuild CHECK constraints after generated column SET EXPRESSION
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox