From: Tom Lane <tgl@sss.pgh.pa.us>
To: joshua.uyehara@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18178: New Restriction on "ON SELECT" rules on tables
In-reply-to: <18178-05534d7064044d2d@postgresql.org>
References: <18178-05534d7064044d2d@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Wed, 01 Nov 2023 23:25:48 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3027423.1698934802.1@sss.pgh.pa.us>
Date: Thu, 02 Nov 2023 10:20:02 -0400
Message-ID: <3027424.1698934802@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3027424.1698934802%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> The documentation for rules specifically states that "ON SELECT" rules can
> be created on tables (and I have functionality/use cases that rely on that)
> behavior, but pg16 breaks that.

If the documentation still says that, it needs to be updated.
What are you looking at precisely?

> The issue is, basically, that there are broad classes of database
> abstraction middleware that are configured via database introspection at
> runtime and do not understand or implement the concept of updateable views
> and foreign tables.  The easiest workaround for that limitation in postgres
> has always been to create a local table stand-in with all operations
> rerouted to the foreign table via rules.

TBH, I don't believe that argument for a second.  Pre-v16, what
happened when you added an ON SELECT rule to a table is that *the
table got changed into a view* (which is what caused the bugs
mentioned in the thread Daniel pointed you to).  There is no
difference between the subsequent catalog state and what you would
have if you'd just created it as a view in the first place.  So
do that and then add whatever non-SELECT rules you need, and you
should be in the same place as before (and your code will still
work with pre-v16 releases, too).

			regards, tom lane