Dumping policy on a table belonging to an extension is expected?

From: Amul Sul <sulamul(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Dumping policy on a table belonging to an extension is expected?
Date: 2023-07-05 06:05:15
Message-ID: CAAJ_b97JiNVVoDMswSnMkTS0XHRK4GY4Vi6o8MJgonnNskNWAA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I have a ROW LEVEL SECURITY policy on the table part of an extension, and
while
dumping the database where that extension is installed, dumps the policy of
that table too even though not dumpling that table .

Here is quick tests, where I have added following SQL to adminpack--1.0.sql
extension file:

CREATE TABLE public.foo (i int CHECK(i > 0));
ALTER TABLE public.foo ENABLE ROW LEVEL SECURITY;
CREATE POLICY foo_policy ON public.foo USING (true);

After installation and creation of this extension, the dump output will have
policy without that table:

--
-- Name: foo; Type: ROW SECURITY; Schema: public; Owner: amul
--

ALTER TABLE public.foo ENABLE ROW LEVEL SECURITY;

--
-- Name: foo foo_policy; Type: POLICY; Schema: public; Owner: amul
--

CREATE POLICY foo_policy ON public.foo USING (true);

I am not sure if that is expected behaviour. The code comment in
checkExtensionMembership() seems to be doing intentionally:

* In 9.6 and above, mark the member object to have any non-initial ACL,
* policies, and security labels dumped.

The question is why were we doing this? Shouldn't skip this policy if it is
part of the create-extension script?

Also, If you try to drop this policy, get dropped without any warning/error
unlike tables or other objects which are not allowed to drop at all.

--
Regards,
Amul Sul
EDB: http://www.enterprisedb.com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2023-07-05 06:15:48 Re: Incremental sort for access method with ordered scan support (amcanorderbyop)
Previous Message Thomas Munro 2023-07-05 06:00:25 Re: pg_upgrade and cross-library upgrades