Re: Virtual generated columns

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Tomasz Rybak <tomasz(dot)rybak(at)post(dot)pl>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Virtual generated columns
Date: 2024-07-01 10:56:22
Message-ID: 0349e562-e2df-471d-8562-5e64c4e4da7b@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17.06.24 21:31, Tomasz Rybak wrote:
> v1-0001-Rename-regress-test-generated-to-generated_stored.patch:
> no objections here, makes sense as preparation for future changes
>
> v1-0002-Put-generated_stored-test-objects-in-a-schema.patch:
> also no objections.
> OTOH other tests (like publication.out, rowsecurity.out, stats_ext.out,
> tablespace.out) are creating schemas and later dropping them - so here
> it might also make sense to drop schema at the end of testing.

The existing tests for generated columns don't drop what they create at
the end, which can be useful for pg_upgrade testing for example. So
unless there are specific reasons to change it, I would leave that as is.

Other tests might have other reasons. For example, publications or row
security might interfere with many other tests.

> v1-0003-Remove-useless-initializations.patch:
> All other cases (I checked directory src/backend/utils/cache)
> calling MemoryContextAllocZero only initialize fields when they
> are non-zero, so removing partial initialization with false brings
> consistency to the code.
>
> v1-0004-Remove-useless-code.patch:
> Patch removes filling in of constraints from function
> BuildDescForRelation. This function is only called from file
> view.c and tablecmds.c (twice). In none of those cases
> result->constr is used, so proposed change makes sense.
> While I do not know code well, so might be wrong here,
> I would apply this patch.

I have committed these two now.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2024-07-01 10:59:13 Re: Virtual generated columns
Previous Message David Rowley 2024-07-01 10:49:07 Re: Make tuple deformation faster