Re: FOR PORTION OF does not recompute GENERATED STORED columns that depend on the range column
Paul A Jungwirth <pj@illuminatedcomputing.com>
From: Paul A Jungwirth <pj@illuminatedcomputing.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: jian he <jian.universality@gmail.com>, Chao Li <li.evan.chao@gmail.com>, Peter Eisentraut <peter@eisentraut.org>,
SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-05-13T00:05:03Z
Lists: pgsql-hackers
Attachments
- v1-0001-Forbid-GENERATED-columns-in-FOR-PORTION-OF.patch (text/x-patch)
On Tue, May 12, 2026 at 1:34 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> FOR PORTION OF doesn't seem to work well with virtual generated columns,
> either. The following example seg-faults on my machine:
>
> create table t (a int, b int4range generated always as (int4range(a, a + 1)) virtual);
> insert into t values (1);
> delete from t for portion of b from 1 to 2;
Thanks for catching this!
Here is a patch forbidding both STORED and VIRTUAL columns here. There
is a follow-up patch (not for v19) to add SQL:2011 PERIODs, which will
be based on STORED columns, so we will eventually allow those (if they
belong to a PERIOD), but it seems right to forbid them for now.
I put the check in the analysis phase to match what we have already,
but based on [1] that is apparently premature. I think I'd like to
move all those things together in a single commit though.
I did experiment with putting just this check in ExecInitModifyTable.
But (1) the planner will already reject the UPDATE case with a
different error message, and (2) it doesn't really improve anything,
since rangeVar gets looked up during analysis anyway (until we address
the rest of [1]).
[1] https://www.postgresql.org/message-id/626986.1776785090%40sss.pgh.pa.us
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com