On Sun, Jan 28, 2024 at 11:26 AM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Odhiambo Washington writes:
The issue you're dealing with in that case is this change in PostgreSQL-15 discussed in this blog:
https://www.cybertec-postgresql.com/en/error-permission-denied-schema-public...
Thank you for the reference!
If you have a Mailman-only host, with a Mailman-only PostgreSQL, or The Cabal of equally responsible maintainers are the only people who work on the Postgres cluster, the two approaches are basically equivalent.
My take is that the default "right thing" is to transfer ownership of the 'mailman' database to the 'mailman' user, and use "GRANT ALL ON SCHEMA public TO fred" in the case that you don't want to give "sudo mailman" to Fred.
Rationale: I believe there are a number of things that the 'postgres' user can do that other users cannot, and you probably don't want random contractors or new volunteers to have those privileges. On the principlee that 'postgres' should only do those things that only 'postgres' can do, you want to make the 'mailman' user the owner of the 'mailman' database (and 'mailmanweb' too if you go that route). Then if you have a user 'fred' who may be working on both mailman and non-mailman databases in a session, then instead of giving sudo mailman to Fred, 'mailman' can grant all on schema public in mailman to 'fred'.
It's a really fine difference, and probably will matter to almost nobody running Mailman 3. I do think
user 'mailman' owns the 'mailman' databaseis conceptually simpler than
user 'postgres owns the 'mailman' database and 'mailman' has ALL privilege on the PUBLIC schemaRight?
Right! That makes more sense.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]