Re: Good News Everyone! + feature proposal

Поиск
Список
Период
Сортировка
От Jon Erdman
Тема Re: Good News Everyone! + feature proposal
Дата
Msg-id 0101018b00588dfc-d6e2ff80-0590-4974-8902-2f2454b1ce64-000000@us-west-2.amazonses.com
обсуждение исходный текст
Ответ на Re: Good News Everyone! + feature proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Good News Everyone! + feature proposal  (Julien Rouhaud <rjuju123@gmail.com>)
Re: Good News Everyone! + feature proposal  (Laurenz Albe <laurenz.albe@cybertec.at>)
Список pgsql-hackers
On 10/5/23 8:53 AM, Tom Lane wrote:
> Laurenz Albe <laurenz.albe@cybertec.at> writes:
>> On Thu, 2023-10-05 at 02:22 +0000, Jon Erdman wrote:
>>> For the proposal (this one is a bit Apple specific): because my team
>>> offers managed postgres to our Apple-internal customers, many of whom
>>> are not database experts, or at least not postgres experts, we'd like to
>>> be able to toggle the availability of UNLOGGED tables in
>>> postgresql.conf, so our less clueful users have fewer footguns.
> 
> I'm doubtful that this is a problem that needs a solution.
> If anything, the right answer is to fix whatever part of the
> documentation isn't warning of the hazards strongly enough.
> 
> Even more to the point: if we accept this, how many other
> footgun-preventing GUCs will have the same or stronger claim to
> existence?
> 
>> It certainly sounds harmless, but there are two things that make me
>> unhappy about this:
> 
>> - Yet another GUC.  It's not like we don't have enough of them.
>>    (This is a small quibble.)
> 
>> - This setting would influence the way SQL is processed.
>>    We have had bad experiences with those; an often-quoted example is
>>    the "autocommit" parameter that got removed in 7.4.
>>    This certainly is less harmfuls, but still another pitfall that
>>    can confuse users.
> 
> Same objections here.  Also note that the semantics we've defined
> for GUCs (when they can be set and where) don't always line up
> nicely with requirements of this sort.  It's far from clear to me
> whether such a GUC should be SUSET (making it a hard prohibition
> for ordinary users) or USERSET (making it just a training wheel).

Someone on linked-in suggested an event trigger, so now I'm thinking of 
a custom extension that would do nothing but create said event trigger, 
and maybe could be toggled with a customized setting (but that might 
allow users to turn it off themselves...which is maybe ok).

If the extension were installed by the DBA user, the customer wouldn't 
be able to drop it, and if we decided to give them an exception, we just 
drop or disable the extension.

As a second more general question: could my original idea (i.e. sans 
event trigger) be implemented in an extension somehow, or is that not 
technically possible (I suspect not)?
-- 
Jon Erdman (aka StuckMojo on IRC)
     PostgreSQL Zealot



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Allow tests to pass in OpenSSL FIPS mode
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Remove distprep