| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | jian he <jian(dot)universality(at)gmail(dot)com>, Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | Zhang Mingli <zmlpostgres(at)gmail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Virtual generated columns |
| Date: | 2025-02-14 10:59:48 |
| Message-ID: | d23c8a44-9124-4eaa-af90-e5482b3b4680@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 13.02.25 14:06, jian he wrote:
> I didn't solve the out join semantic issue.
> i am wondering, can we do the virtual generated column expansion in
> the rewrite stage as is,
> and wrap the expressions in PHVs if the virtual generated
> columns come from the nullable side of an outer join.
PlaceHolderVar looks like a fitting mechanism for this. But it's so far
a planner node, so it might take some additional consideration if we
want to expand where it's used.
Maybe a short-term fix would be to error out if we find ourselves about
to expand a Var with varnullingrels != NULL. That would mean you
couldn't use a virtual generated column on the nullable output side of
an outer join, which is annoying but not fatal, and we could fix it
incrementally later.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2025-02-14 11:26:19 | Re: pg_stat_statements and "IN" conditions |
| Previous Message | Dmitry Dolgov | 2025-02-14 10:47:42 | Re: pg_stat_statements and "IN" conditions |