Re: CREATE ROLE IF NOT EXISTS - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: CREATE ROLE IF NOT EXISTS
Date
Msg-id 20211109161650.GQ20998@tamriel.snowman.net
Whole thread Raw
In response to Re: CREATE ROLE IF NOT EXISTS  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers
Greetings,

* Mark Dilger (mark.dilger@enterprisedb.com) wrote:
> > On Nov 9, 2021, at 7:36 AM, David Christensen <david.christensen@crunchydata.com> wrote:
> > If CINE semantics are at issue, what about the CREATE OR REPLACE semantics with some sort of merge into the
existingrole?  I don't care strongly about which approach is taken, just think the overall "make this role exist in
thisform" without an error is useful in my own work, and CINE was easier to implement as a first pass. 
>
> CREATE OR REPLACE might be a better option, not with the "merge into the existing role" part, but rather as
drop+create. If a malicious actor has already added other roles to the role, or created a table with a malicious
triggerdefinition, the drop part will fail, which is good from a security viewpoint.  Of course, the drop portion will
alsofail under other conditions which don't entail any security concerns, but maybe they could be addressed in a series
offollow-on patches? 
>
> I understand this idea is not as useful for creating idempotent scripts, but maybe it gets you part of the way there?

If it's actually drop+create then, no, that isn't really useful because
it'll fail when that role owns objects (see my other email).  If we can
avoid that issue then CREATE OR REPLACE might work, we just need to make
sure that we document what is, and isn't, done in such a case.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: CREATE ROLE IF NOT EXISTS
Next
From: vignesh C
Date:
Subject: Removed unused import modules from tap tests