From: | "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Names of run-time configuration parameters (was: Limiting the operations that client-side code can perform upon its database backend's artifacts) |
Date: | 2022-10-01 12:05:53 |
Message-ID: | 20221001120553.b7z7pujnmsllgn5b@hjp.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2022-09-30 17:59:01 -0700, Bryn Llewellyn wrote:
> set rls.tenant_id=42;
This works because there is a "." in the name. Without the "."
PostgreSQL complains:
hjp=> set rls_tenant_id=42;
ERROR: unrecognized configuration parameter "rls_tenant_id"
I think I sort of knew this but had forgotten about it, so checked the
manual for the exact rules. Unfortunately I couldn't find them (I
checked https://www.postgresql.org/docs/14/sql-set.html,
https://www.postgresql.org/docs/14/config-setting.html,
https://www.postgresql.org/docs/14/functions-admin.html#FUNCTIONS-ADMIN-SET,
and browser the table of content and the index).
From the documentation I get the impression that you can only set
existing parameters, not your own.
I therefore suggest adding something like this to the section
"configuration_parameter" in
https://www.postgresql.org/docs/14/sql-set.html:
| In addition, any name including a single dot (".") can be set. This
| allows an application to define its own run-time parameters. Using the
| application name as a prefix reduces the probability of name conflicts
| with other applications or extensions.
(This of course assumes that the behaviour is intentional and not a
bug.)
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp(at)hjp(dot)at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
From | Date | Subject | |
---|---|---|---|
Next Message | Peter J. Holzer | 2022-10-01 12:20:00 | Re: Example code Re: Singleton SELECT inside cursor loop |
Previous Message | Peter J. Holzer | 2022-10-01 11:22:54 | Re: Limiting the operations that client-side code can perform upon its database backend's artifacts |