čt 3. 6. 2021 v 21:11 odesílatel Mark Dilger <mark.dil...@enterprisedb.com> napsal:
> > > > On Jun 3, 2021, at 12:06 PM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > > > > > > > čt 3. 6. 2021 v 20:25 odesílatel Mark Dilger < > mark.dil...@enterprisedb.com> napsal: > > > > > > > On Jun 3, 2021, at 9:38 AM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > > > > > This design looks good for extensions, but I am not sure if it is good > for users. Some declarative way without necessity to programming or install > some extension can be nice. > > > > I agree, though "some declarative way" is a bit vague. I've had ideas > that perhaps superusers should be able to further restrict the [min,max] > fields of int and real GUCs. Since -1 is sometimes used to mean > "disabled", syntax to allow specifying a set might be necessary, something > like [-1, 60..600]. For text and enum GUCs, perhaps a set of regexps would > work, some being required to match and others being required not to match, > such as: > > > > search_path !~ '\mcustomerx\M' > > search_path ~ '^pg_catalog,' > > > > If we did something like this, we'd need it to play nicely with other > filters provided by extensions, because I'm reasonably sure not all filters > could be done merely using set notation and regular expression syntax. In > fact, I find it hard to convince myself that set notation and regular > expression syntax would even be useful in a large enough number of cases to > be worth implementing. What are your thought on that? > > > > I don't think so for immutable strings we need regular expressions. > Maybe use some special keyword > > > > search_path only "pg_catalog" > > I think we're trying to solve different problems. I'm trying to allow > non-superusers to set GUCs while putting constraints on what values they > choose. You appear to be trying to revoke the ability to set a GUC by > forcing it to only ever have a single value. > My proposal doesn't mean the search_path cannot be changed - it limits possible values like your patch. Maybe we can get inspiration from pg_hba.conf > > — > Mark Dilger > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > >
