> 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.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
