Horton

Re: Virtual generated columns

Peter Eisentraut <peter@eisentraut.org>

View thread
From: Peter Eisentraut <peter@eisentraut.org>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: jian he <jian.universality@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-08-21T07:00:44Z
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 →

  1. Expand virtual generated columns for ALTER COLUMN TYPE

  2. Eliminate code duplication in replace_rte_variables callbacks

  3. Expand virtual generated columns in the planner

  4. Virtual generated columns

  5. Additional tests for stored generated columns

  6. Improve generated_stored test

  7. Fix handling of CREATE DOMAIN with GENERATED constraint syntax

  8. Add pg_constraint rows for not-null constraints

  9. Put generated_stored test objects in a schema

  10. Rename regress test generated to generated_stored

  11. Small code simplification

  12. Remove useless code

  13. Remove useless initializations

  14. doc: Clarify that pg_attrdef also stores generation expressions

  15. Clean out column-level pg_init_privs entries when dropping tables.

  16. Re-implement the ereport() macro using __VA_ARGS__.

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?

> I think it might be better to do this from within fireRIRrules(), just
> after RLS policies are applied, so it wouldn't need to worry about
> CTEs and sublink subqueries. That would also make the
> hasGeneratedVirtual flags unnecessary, since we'd already only be
> doing the extra work for tables with virtual generated columns. That
> would eliminate possible bugs caused by failing to set those flags.

Yes, ideally, we'd piggy-back this into fireRIRrules().  One thing I'm 
missing is that if you're descending into subqueries, there is no link 
to the upper levels' range tables, which we need to lookup the 
pg_attribute entries of column referencing Vars.  That's why there is 
this whole custom walk with its own context data.  Maybe there is a way 
to do this already that I missed?