Re: Fix tuple deformation with virtual generated NOT NULL columns

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix tuple deformation with virtual generated NOT NULL columns
Date: 2026-06-17 05:04:43
Message-ID: CAApHDvrJBXEhet4=Es_wHBKdv5PCV5OGCaJOSmJexeaFqfmUHA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 12 Jun 2026 at 16:26, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> However, I don't object to adding the test if others feel it's
> worthwhile, but on looking at the patch, there are a couple of things
> that stand out.
>
> 1. Nothing has been done for the comment at the top of the file that
> says "-- keep these tests aligned with generated_stored.sql". It
> looks like there have been quite a few commits already which have
> neglected this. Maybe that means we should do away with the comment
> rather than try to align the two.

I pushed the patch to add the new test after modifying it to also
include the change in the generated_stored test, but with it commented
out. This is the method that 83ea6c540 introduced.

Since a few commits have already put these files out of sync, maybe we
should consider having a single test file that we include with \i
after doing something like:

\set generated_type STORED
\set test_generated_stored true
\set test_generated_virtual false
\i generated_generic.sql

and have generated_generic.sql use \if test_generated_(stored|virtual)
as and when required.

> 2. I can't quite figure out the pattern in these tests for dropping vs
> not dropping the tables at the end of the test. Many tests do DROP
> TABLE and a large number of others don't bother. What's meant to be
> happening here?

I added the DROP TABLE too, as I didn't see any reason mentioned
anywhere that they should be kept.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul A Jungwirth 2026-06-17 05:10:48 FOR PORTION OF should not allow WHERE CURRENT OF
Previous Message Ayush Tiwari 2026-06-17 04:59:36 Re: faulty error handling around pgstat_count_io_op_time()