Re: Virtual generated columns - Mailing list pgsql-hackers
From | jian he |
---|---|
Subject | Re: Virtual generated columns |
Date | |
Msg-id | CACJufxE+E-iYmBnZVZHiYA+WpyZZVv7BfiBLpo=T70EZHDU9rw@mail.gmail.com Whole thread Raw |
In response to | Re: Virtual generated columns (Peter Eisentraut <peter@eisentraut.org>) |
Responses |
Re: Virtual generated columns
Re: Virtual generated columns |
List | pgsql-hackers |
On Thu, May 23, 2024 at 1:23 AM Peter Eisentraut <peter@eisentraut.org> wrote: > > On 29.04.24 10:23, Peter Eisentraut wrote: > > Here is a patch set to implement virtual generated columns. > > > The main feature patch (0005 here) generally works but has a number of > > open corner cases that need to be thought about and/or fixed, many of > > which are marked in the code or the tests. I'll continue working on > > that. But I wanted to see if I can get some feedback on the test > > structure, so I don't have to keep changing it around later. the test structure you made ( generated_stored.sql, generated_virtual.sq) looks ok to me. but do we need to reset the search_path at the end of generated_stored.sql, generated_virtual.sql? most of the test tables didn't use much storage, maybe not necessary to clean up (drop the test table) at the end of sql files. > > So, I think this basically works now, and the things that don't work > should be appropriately prevented. So if someone wants to test this and > tell me what in fact doesn't work correctly, that would be helpful. in https://www.postgresql.org/docs/current/catalog-pg-attrdef.html >>> The catalog pg_attrdef stores column default values. The main information about columns is stored in pg_attribute. Only columns for which a default value has been explicitly set will have an entry here. >> didn't mention generated columns related expressions. Do we need to add something here? maybe a separate issue? + /* + * TODO: This could be done, but it would need a different implementation: + * no rewriting, but still need to recheck any constraints. + */ + if (attTup->attgenerated == ATTRIBUTE_GENERATED_VIRTUAL) + ereport(ERROR, + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), + errmsg("ALTER TABLE / SET EXPRESSION is not supported for virtual generated columns"), + errdetail("Column \"%s\" of relation \"%s\" is a virtual generated column.", + colName, RelationGetRelationName(rel)))); minor typo, should be + errmsg("ALTER TABLE SET EXPRESSION is not supported for virtual generated columns"), insert/update/delete/merge returning have problems: CREATE TABLE t2 ( a int , b int GENERATED ALWAYS AS (a * 2), d int default 22); insert into t2(a) select g from generate_series(1,10) g; insert into t2 select 100 returning *, (select t2.b), t2.b = t2.a * 2; update t2 set a = 12 returning *, (select t2.b), t2.b = t2.a * 2; update t2 set a = 12 returning *, (select (select t2.b)), t2.b = t2.a * 2; delete from t2 where t2.b = t2.a * 2 returning *, 1,((select t2.b)); currently all these query, error message is "unexpected virtual generated column reference" we expect above these query work? issue with merge: CREATE TABLE t0 (a int PRIMARY KEY, b int GENERATED ALWAYS AS (a * 2) VIRTUAL); insert into t0(a) select g from generate_series(1,10) g; MERGE INTO t0 t USING t0 AS s ON 2 * t.a = s.b WHEN MATCHED THEN DELETE returning *; the above query returns zero rows, but for stored generated columns it will return 10 rows. in transformMergeStmt(ParseState *pstate, MergeStmt *stmt) add `qry->hasGeneratedVirtual = pstate->p_hasGeneratedVirtual;` before `assign_query_collations(pstate, qry);` solve the problem.
pgsql-hackers by date: