Re: generating function default settings from pg_proc.dat

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: generating function default settings from pg_proc.dat
Date: 2026-02-19 17:53:49
Message-ID: 2659121.1771523629@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> However, I'm not sure I love it in this form, because what it
> asks developers to do is populate proacl using aclitemin's
> notation, eg
> + proacl => '{postgres=X/postgres,pg_read_all_stats=X/postgres}' },

After sleeping on it, I decided that much of the cognitive dissonance
here comes from the fact that elsewhere in the catalog data files
we represent the bootstrap user's name as POSTGRES, making it more
obvious that that's a placeholder and not the real value. If we do
that here and also drop the redundant grantor specifications, we get

+ proacl => '{POSTGRES=X,pg_read_all_stats=X}' },

which is still not the world's prettiest notation, but it feels
manageable for this purpose.

I tried to write it that way and found that it failed miserably,
because initdb tried to substitute the real superuser's name
for POSTGRES, and we don't want that here (the bootstrap backend
can't possibly know what that is yet). So 0001 attached is a
preliminary patch to tighten initdb so it only replaces complete
tokens bounded by whitespace, rather than any arbitrary substrings
of postgres.bki lines. (Note this depends on 2f248ad57.) Then
0002 is the same patch as before plus this notational adjustment.

regards, tom lane

Attachment Content-Type Size
v2-0001-Be-more-wary-of-false-matches-in-initdb-s-replace.patch text/x-diff 3.1 KB
v2-0002-Simplify-creation-of-built-in-functions-with-non-.patch text/x-diff 47.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ants Aasma 2026-02-19 17:55:06 Re: pg_stat_io_histogram
Previous Message Dmitry Dolgov 2026-02-19 17:44:57 Add ssl_(supported|shared)_groups to sslinfo