Re: FOR PORTION OF does not recompute GENERATED STORED columns that depend on the range column

From: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: FOR PORTION OF does not recompute GENERATED STORED columns that depend on the range column
Date: 2026-05-13 15:42:53
Message-ID: CA+renyVYc-0Swt2sR7vd3V-fu+3s0pZKU9McyznRnzSr1=oeZA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 12, 2026 at 5:05 PM Paul A Jungwirth
<pj(at)illuminatedcomputing(dot)com> wrote:
>
> On Tue, May 12, 2026 at 1:34 PM Nathan Bossart <nathandbossart(at)gmail(dot)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

I started a new thread for this issue and made a CF entry. Please see:

- https://www.postgresql.org/message-id/CA%2BrenyVRPyP5TNgEBe%3DhRT1ZR3%3DzWCZLXkAwp5xbWeS_TaMxOA%40mail.gmail.com
- https://commitfest.postgresql.org/patch/6764/

Yours,

--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-05-13 15:55:43 Re: egrep is obsolescent
Previous Message Paul A Jungwirth 2026-05-13 15:39:43 FOR PORTION OF should reject GENERATED columns