Re: Does rewriteTargetListIU still need to add UPDATE tlist entries? - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Does rewriteTargetListIU still need to add UPDATE tlist entries?
Date
Msg-id CAEZATCW3efqgUY3F1DNB7O_9QiBTad3K4dZWppPREg=_ej=dzw@mail.gmail.com
Whole thread Raw
In response to Re: Does rewriteTargetListIU still need to add UPDATE tlist entries?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 26 Apr 2021 at 15:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I checked into the commit history (how'd we ever survive without "git
> blame"?) and found that my argument above is actually wrong in detail.
> Before cab5dc5da of 2013-10-18, rewriteTargetListIU expanded non-updated
> columns for all views not only trigger-updatable ones.  However, that
> behavior itself goes back only to 2ec993a7c of 2010-10-10, which added
> triggers on views; before that there was indeed no such expansion.

Ah, that makes sense. Before cab5dc5da, expanding non-updated columns
of auto-updatable views was safe because until then a view was only
auto-updatable if all it's columns were. It was still unnecessary work
though, and with 20/20 hindsight, when triggers on views were first
added in 2ec993a7c, it probably should have only expanded the
targetlist for trigger-updatable views.

> Of course the view rewrite mechanisms are ten or so years older than
> that, so the conclusion that they weren't designed to need this still
> stands.

Yeah, I think that conclusion is right. The trickiest part I found was
deciding whether any product queries from conditional rules would do
the right thing if the main trigger-updatable query no longer expands
its targetlist. But I think that has to be OK, because even before
trigger-updatable views were added, it was possible to have product
queries from conditional rules together with an unconditional
do-nothing rule, so the product queries don't rely on the expanded
targetlist, and never have.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: compute_query_id and pg_stat_statements
Next
From: Tom Lane
Date:
Subject: Re: compute_query_id and pg_stat_statements