Re: Virtual generated columns
Peter Eisentraut <peter@eisentraut.org>
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
Attachments
- v6-0001-Virtual-generated-columns.patch (text/plain) patch v6-0001
- v6-0002-Use-ReplaceVarsFromTargetList-for-rewriting-virtu.patch (text/plain) patch v6-0002
On 21.08.24 12:51, Dean Rasheed wrote: > On Wed, 21 Aug 2024 at 08:00, Peter Eisentraut<peter@eisentraut.org> wrote: >> On 08.08.24 20:22, Dean Rasheed wrote: >>> Looking at the rewriter changes, it occurred to me that it could >>> perhaps be done more simply using ReplaceVarsFromTargetList() for each >>> RTE with virtual generated columns. That function already has the >>> required wholerow handling code, so there'd be less code duplication. >> Hmm, I don't quite see how ReplaceVarsFromTargetList() could be used >> here. It does have the wholerow logic that we need somehow, but other >> than that it seems to target something different? >> > Well what I was thinking was that (in fireRIRrules()'s final loop over > relations in the rtable), if the relation had any virtual generated > columns, you'd build a targetlist containing a TLE for each one, > containing the generated expression. Then you could just call > ReplaceVarsFromTargetList() to replace any Vars in the query with the > corresponding generated expressions. That takes care of descending > into subqueries, adjusting varlevelsup, and expanding wholerow Vars > that might refer to the generated expression. > > I also have half an eye on how this patch will interact with my patch > to support RETURNING OLD/NEW values. If you use > ReplaceVarsFromTargetList(), it should just do the right thing for > RETURNING OLD/NEW generated expressions. Here is an implementation of this. It's much nicer! It also appears to fix all the additional test cases that have been presented. (I haven't integrated them into the patch set yet.) I left the 0001 patch alone for now and put the new rewriting implementation into 0002. (Unfortunately, the diff is kind of useless for visual inspection.) Let me know if this matches what you had in mind, please. Also, is this the right place in fireRIRrules()?