Re: CREATE ROLE IF NOT EXISTS

From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
To: David Christensen <david(dot)christensen(at)crunchydata(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CREATE ROLE IF NOT EXISTS
Date: 2021-11-09 15:55:54
Message-ID: F57B443F-68E0-414E-BDC1-5A37D03A7F99@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Nov 9, 2021, at 7:36 AM, David Christensen <david(dot)christensen(at)crunchydata(dot)com> wrote:
>
> If CINE semantics are at issue, what about the CREATE OR REPLACE semantics with some sort of merge into the existing role? I don't care strongly about which approach is taken, just think the overall "make this role exist in this form" 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 trigger definition, the drop part will fail, which is good from a security viewpoint. Of course, the drop portion will also fail under other conditions which don't entail any security concerns, but maybe they could be addressed in a series of follow-on patches?

I understand this idea is not as useful for creating idempotent scripts, but maybe it gets you part of the way there?


Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2021-11-09 15:57:03 Re: Identify missing publications from publisher while create/alter subscription.
Previous Message Peter Eisentraut 2021-11-09 15:49:24 Re: [RFC] building postgres with meson -v