From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Subject: | Re: Virtual generated columns |
Date: | 2024-11-12 16:17:16 |
Message-ID: | 4ce78b84-f59b-4915-bb85-baba9b53e6c6@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10.11.24 04:16, Amit Kapila wrote:
> The possible idea to replicate virtual generated columns is to compute
> the corresponding expression before sending the data to the client. If
> we can allow it in the row filter than why not to publish it as well.
Row filters have pretty strong restrictions for what kind of operations
they can contain. Applying those restrictions to virtual generated
columns would probably not make that feature very useful. (You want to
use virtual columns for expressions that are too cumbersome to write out
by hand every time.)
Moreover, we would have to implement some elaborate cross-checks if a
table gets added to a publication. How would that work? "Can't add
table x to publication because it contains a virtual generated column
with a non-simple expression"? With row filters, this is less of a
problem, because the row filter a property of the publication.
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2024-11-12 16:32:36 | Re: define pg_structiszero(addr, s, r) |
Previous Message | Peter Eisentraut | 2024-11-12 16:10:57 | Re: Virtual generated columns |