Message-ID: <66f55a6b9ff7bdd6bfd0d05e8fd8351690e69e23.camel@j-davis.com>
Subject: Re: Non-superuser subscription owners
From: Jeff Davis <pgsql@j-davis.com>
To: Mark Dilger <mark.dilger@enterprisedb.com>, Amit Kapila
	 <amit.kapila16@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development
	 <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: Wed, 24 Nov 2021 16:30:06 -0800
In-Reply-To: <7C62876F-5D19-4B5C-96AC-5590B10A49B2@enterprisedb.com>
References: <9DFC88D3-1300-4DE8-ACBC-4CEF84399A53@enterprisedb.com>
	 <c1c334a2-5d85-687f-f0dc-0ac8c422ca1a@dunslane.net>
	 <CD02D159-7260-4247-888F-2CFA7AD3798D@enterprisedb.com>
	 <6BB4451E-7B1B-474C-BD1F-DB7531E720C6@enterprisedb.com>
	 <aa28945f9f348307c8ac833a937b5fca732668b8.camel@j-davis.com>
	 <6A2B0FF6-CC86-48CE-B0D3-5401AA5CFEA9@enterprisedb.com>
	 <b6f6ed921b6e219875801857204b14bbc8782e5e.camel@j-davis.com>
	 <CF56AC0D-7495-4E8D-A48F-FF38BD8074EB@enterprisedb.com>
	 <CAA4eK1KHE_xmxk==CqTcTzceC_n00tRWBLm3DGUWhaaPTguz3A@mail.gmail.com>
	 <1BB0A553-3FE9-4A91-A975-6F9D8C157FBD@enterprisedb.com>
	 <CAA4eK1LBjtqHH2h4TO7FHG=FJRfygfkeEb7AFj-dh6rqg3xqUA@mail.gmail.com>
	 <CC5DAC9C-F767-4256-BFEF-32D5A566D254@enterprisedb.com>
	 <7C62876F-5D19-4B5C-96AC-5590B10A49B2@enterprisedb.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/66f55a6b9ff7bdd6bfd0d05e8fd8351690e69e23.camel%40j-davis.com>
Precedence: bulk

On Fri, 2021-11-19 at 16:45 -0800, Mark Dilger wrote:
> Renamed as 0001 in version 3, as it is the only remaining patch.  For
> anyone who reviewed the older patch set, please note that I made some
> changes to the src/test/subscription/t/026_nosuperuser.pl test case
> relative to the prior version.

We need to do permission checking for WITH CHECK OPTION and RLS. The
patch right now allows the subscription to write data that an RLS
policy forbids.

A couple other points:

 * We shouldn't refer to the behavior of previous versions in the docs
unless there's a compelling reason
 * Do we need to be smarter about partitioned tables, where an insert
can turn into an update?
 * Should we refactor to borrow logic from ExecInsert so that it's less
likely that we miss something in the future?

Regards,
	Jeff Davis