| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
| Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Virtual generated columns |
| Date: | 2024-09-09 06:02:54 |
| Message-ID: | ef7c466d-e3b9-4d60-bc03-cd9b48581442@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 04.09.24 12:33, Dean Rasheed wrote:
>> 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()?
> Yes, that's what I had in mind except that it has to be called from
> the second loop in fireRIRrules(), after any RLS policies have been
> added, because it's possible for a RLS policy expression to refer to
> virtual generated columns. It's OK to do it in the same loop that
> expands RLS policies, because such policies can only refer to columns
> of the same relation, so once the RLS policies have been expanded for
> a given relation, nothing else should get added to the query that can
> refer to columns of that relation, at that query level, so at that
> point it should be safe to expand virtual generated columns.
If I move the code like that, then the postgres_fdw test fails. So
there is some additional interaction there that I need to study.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2024-09-09 06:06:40 | Re: Virtual generated columns |
| Previous Message | Nitin Motiani | 2024-09-09 05:25:32 | Re: race condition in pg_class |