Re: Virtual generated columns

Peter Eisentraut <peter@eisentraut.org>

From: Peter Eisentraut <peter@eisentraut.org>

To: jian he <jian.universality@gmail.com>

Cc: Dean Rasheed <dean.a.rasheed@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2024-11-05T16:21:42Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Expand virtual generated columns for ALTER COLUMN TYPE
- 5069fef1cfae 18.0 landed
Eliminate code duplication in replace_rte_variables callbacks
- 363a6e8c6fcf 18.0 landed
Expand virtual generated columns in the planner
- 1e4351af329f 18.0 landed
Virtual generated columns
- 83ea6c54025b 18.0 landed
Additional tests for stored generated columns
- 41084409f635 18.0 landed
Improve generated_stored test
- 44b61efb7928 18.0 landed
- 86749ea3b766 18.0 landed
Fix handling of CREATE DOMAIN with GENERATED constraint syntax
- 84a67725cd11 18.0 landed
Add pg_constraint rows for not-null constraints
- 14e87ffa5c54 18.0 cited
Put generated_stored test objects in a schema
- 894be11adfa6 18.0 landed
Rename regress test generated to generated_stored
- b9ed4969250d 18.0 landed
Small code simplification
- 7ff9afbbd1df 18.0 landed
Remove useless code
- e26d313bad92 18.0 landed
Remove useless initializations
- da2aeba8f533 18.0 landed
doc: Clarify that pg_attrdef also stores generation expressions
- da486d360103 18.0 landed
Clean out column-level pg_init_privs entries when dropping tables.
- 76618097a6c0 17.0 cited
Re-implement the ereport() macro using __VA_ARGS__.
- e3a87b4991cc 13.0 cited

On 18.09.24 04:38, jian he wrote:
> On Mon, Sep 16, 2024 at 5:22 PM jian he <jian.universality@gmail.com> wrote:
>>
>> in v7.
>>
> seems I am confused with the version number.
> 
> here, I attached another minor change in tests.
> 
> make
> ERROR:  invalid ON DELETE action for foreign key constraint containing
> generated column
> becomes
> ERROR:  foreign key constraints on virtual generated columns are not supported

I think the existing behavior is fine.  The first message is about 
something that is invalid anyway.  The second message is just that 
something is not supported yet.  If we end up implementing, then users 
will get the first message.

> change contrib/pageinspect/sql/page.sql
> expand information on t_infomask, t_bits information.

added to v8 patch

> change RelationBuildLocalRelation
> make the transient TupleDesc->TupleConstr three bool flags more accurate.

I don't think we need that.  At the time this is used, the generation 
expressions are not added to the table yet.  Note that stored generated 
columns are not dealt with here either.  If there is a bug, then we can 
fix it, but if not, then I'd rather keep the code simpler.