Re: Virtual generated columns
jian he <jian.universality@gmail.com>
Commits
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 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.