Re: Configuration Parameter/GUC value validation hook - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Configuration Parameter/GUC value validation hook
Date
Msg-id CA+Tgmoa+mXD0Oo1GBW1gtZrKBxf8rcTTQaBoFE8ukn4HZqdB-A@mail.gmail.com
Whole thread Raw
In response to Re: Configuration Parameter/GUC value validation hook  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Configuration Parameter/GUC value validation hook
List pgsql-hackers
On Tue, May 3, 2022 at 11:45 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > I have some desire here to see us solve this problem not just for
> > service providers, but for users in general. You don't have to be a
> > service provider to want to disallow SET work_mem = '1TB' -- you just
> > need to be a DBA on a system where such a setting will cause bad
> > things to happen. But, if you are a DBA on some random system, you
> > won't likely find a hook to be a particularly useful way of
> > controlling this sort of thing.
>
> Yeah, I think this is a more realistic point.  I too am not sure what
> a good facility would look like.  I guess an argument in favor of
> providing a hook is that we could then leave it to extension authors
> to try to devise a facility that's useful to end users, rather than
> having to write an in-core feature.

RIght. The counter-argument is that if we just do that, then what will
likely happen is that people who buy PostgreSQL services from
Microsoft, Amazon, EDB, Crunchy, etc. will end up with reasonable
options in this area, and people who download the source code from the
Internet probably won't. As an open-source project, we might hope to
avoid a scenario where it doesn't work unless you buy something. On
the third hand, half a loaf is better than nothing.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: [PATCH] Log details for client certificate failures
Next
From: Tom Lane
Date:
Subject: Re: fix cost subqueryscan wrong parallel cost