From: | Jon Erdman <jon(at)thewickedtribe(dot)net> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Good News Everyone! + feature proposal |
Date: | 2023-10-05 14:58:05 |
Message-ID: | 0101018b00588dfc-d6e2ff80-0590-4974-8902-2f2454b1ce64-000000@us-west-2.amazonses.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/5/23 8:53 AM, Tom Lane wrote:
> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2023-10-05 15:46:46 | Re: Remove distprep |
Previous Message | Daniel Gustafsson | 2023-10-05 14:17:38 | Re: Allow tests to pass in OpenSSL FIPS mode |