Re: Virtual generated columns - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Virtual generated columns
Date
Msg-id 0f811f71-8c86-4e1b-b3bb-6a535674a440@eisentraut.org
Whole thread Raw
In response to Re: Virtual generated columns  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Virtual generated columns
List pgsql-hackers
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?




pgsql-hackers by date:

Previous
From: zfmohz
Date:
Subject: The json_table function returns an incorrect column type
Next
From: Heikki Linnakangas
Date:
Subject: Re: Taking into account syncrep position in flush_lsn reported by apply worker