Re: FOR PORTION OF silently ignored on views with DO INSTEAD rules

From: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: Ewan Young <kdbase(dot)hack(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: FOR PORTION OF silently ignored on views with DO INSTEAD rules
Date: 2026-09-03 16:08:10
Message-ID: CA+renyU2rRxpKjyj_uA_=S9LWpb6Uu-Q0QFEpTWwkmiJ3FUerw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 2, 2026 at 9:20 PM Ewan Young <kdbase(dot)hack(at)gmail(dot)com> wrote:
>
> An UPDATE/DELETE ... FOR PORTION OF against a view that has an
> unqualified DO INSTEAD rule silently ignores the FOR PORTION OF clause
> and modifies (or deletes) the whole temporal row instead of just the
> requested portion -- no error, no warning:
>
> CREATE TABLE t (id int, valid_at daterange, name text);
> INSERT INTO t VALUES (1, '[2020-01-01,2021-01-01)', 'a');
> CREATE VIEW v AS SELECT * FROM t;
> CREATE RULE v_upd AS ON UPDATE TO v DO INSTEAD
> UPDATE t SET name = NEW.name WHERE id = OLD.id;
>
> UPDATE v FOR PORTION OF valid_at FROM '2020-06-01' TO '2020-07-01'
> SET name = 'b';
> SELECT * FROM t;
> id | valid_at | name
> ----+-------------------------+------
> 1 | [2020-01-01,2021-01-01) | b -- whole row changed
>
> The same statement on the base table (or a plain auto-updatable view)
> correctly splits the row three ways. DELETE is worse: DELETE ... FOR
> PORTION OF through such a view removes the entire row.

IMO this is working as intended. If you replace the original query, we
shouldn't skip just part of it and still execute one clause. If you
wanted to keep the FOR PORTION OF, your rule would have said that.

I have the same opinion for INSTEAD OF triggers, but we disabled them
for v19 since the issue came up late in the cycle, and trigger
functions have some extra complexity (especially because of DO ATOMIC
functions). It doesn't seem like DO INSTEAD rules have that same
issue. None of the examples here actually look like bugs.

But now we are even later in the cycle than before. If people want to
disable this for v19 too, I'm okay with that. In that case, the patch
looks good to me.

Yours,

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-09-03 16:28:50 Re: Improving display of octal GUCs
Previous Message David Geier 2026-09-03 16:02:23 Re: Reducing relcache memory usage: deduping index shapes