Re: support virtual generated column not null constraint

From: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: Xuneng Zhou <xunengzhou(at)gmail(dot)com>, Navneet Kumar <thanit3111(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: support virtual generated column not null constraint
Date: 2025-03-19 16:19:24
Message-ID: 202503191619.c72arfi34vid@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025-Mar-13, jian he wrote:

> hi.
>
> new patch attached.
>
> 0001 for virtual generated columns not null.
> minor change to fix the compiler warning.

I gave a look at 0001, and I propose some fixes. 0001 is just a typo in
an error message. 0002 is pgindent. Then 0003 contain some more
interesting bits:

- in ExecRelCheckGenVirtualNotNull() it seems more natural to an
AttrNumber rather than int, and use the InvalidAttrNumber value rather
than -1 to indicate that all columns are ok. Also, use
foreach_current_index instead of manually counting the loop.

- ATRewriteTable can be simplified if we no longer add the virtual
generated columns with not nulls to the notnulls_attrs list, but instead
we store the attnums in a separate list. That way, the machinery
around ExecRelCheckGenVirtualNotNull made less convoluted.

- in ExecConstraints, you removed a comment (which ended up in
NotNullViolationErrorReport), which was OK as far as that went; but
there was another comment a few lines below which said "See the
comment above", which no longer made sense. To fix it, I duplicated
the original comment in the place where "See the..." comment was.

- renamed NotNullViolationErrorReport to ReportNotNullViolationError.
Perhaps a better name is still possible -- something in line with
ExecPartitionCheckEmitError? (However, that function is exported,
while the new one is not. So we probably don't need an "Exec" prefix
for it. I don't particularly like that name very much anyway.)

- Reduce scope of variables all over the place.

- Added a bunch more comments.

Other comments:

* The block in ATRewriteTable that creates a resultRelInfo for
ExecRelCheckGenVirtualNotNull needs an explanation.

* I suspect the locations for the new functions were selected with
the help of a dartboard. ExecRelCheckGenVirtualNotNull() in
particular looks like it could use a better location. Maybe it's
better right after ExecConstraints, and ReportNotNullViolationError
(or whatever we name it) can go after it.

* I don't find the name all_virtual_nns particularly appropriate. Maybe
virtual_notnull_attrs?

* There are some funny rules around nulls on rowtypes. I think allowing
this tuple is wrong (and I left an XXX comment near where the 'argisrow'
flag is set):

create type twoints as (a int, b int);
create table foo (a int, b int, c twoints generated always as (row(a,b)::twoints) not null);
insert into foo values (null, null);

I don't remember exactly what the rules are though so I may be wrong.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Having your biases confirmed independently is how scientific progress is
made, and hence made our great society what it is today" (Mary Gardiner)

Attachment Content-Type Size
0001-fix-typo-in-errmsg.patch.txt text/plain 2.3 KB
0002-pgindent.patch.txt text/plain 7.5 KB
0003-Some-code-review.patch.txt text/plain 12.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-03-19 16:28:33 Re: optimize file transfer in pg_upgrade
Previous Message Nathan Bossart 2025-03-19 16:09:21 Re: Disabling vacuum truncate for autovacuum