Re: Best Practices for Extensions, limitations and recommended use for monitoring - Mailing list pgsql-general

From Tom Lane
Subject Re: Best Practices for Extensions, limitations and recommended use for monitoring
Date
Msg-id 18652.1534259233@sss.pgh.pa.us
Whole thread Raw
In response to Best Practices for Extensions, limitations and recommended use formonitoring  (Alvar Freude <alvar@a-blast.org>)
Responses Re: Best Practices for Extensions, limitations and recommended usefor monitoring
List pgsql-general
Alvar Freude <alvar@a-blast.org> writes:
> I have a question about best practices writing PostgreSQL extensions. Is it OK to write extensions which create users
andgrant/revoke rights on the created functions to this users? 

I'd say that's generally deprecated.  Per the documentation, you can write
CREATE USER commands in an extension script if you like, but the roles
won't be considered to "belong" to the extension, and won't be dropped
when it is.  This is mainly because roles are cluster-wide but extensions
are only local to one database.  Consider for example what will happen
when somebody tries to load your extension into more than one database in
the same cluster.

> Is it possible to add options to CREATE EXTENSION by the extension itself e.g. to make user names configurable?

No.

For the particular use-case you're describing here, maybe it'd make
sense to grant privileges to the predefined role pg_monitor, which
exists in v10 and up.  v11 has some additional predefined roles that
perhaps would fit in, too.

            regards, tom lane


pgsql-general by date:

Previous
From: Ravi Krishna
Date:
Subject: Re: What is the use case for UNLOGGED tables
Next
From: Jack Cushman
Date:
Subject: Duplicating data folder without tablespace, for read access