From: | David Christensen <david(at)pgguru(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Cary Huang <cary(dot)huang(at)highgo(dot)ca> |
Subject: | Re: [PATCH] Proof of concept for GUC improvements |
Date: | 2022-03-22 18:15:34 |
Message-ID: | E8E43736-060D-4FD2-BC4A-4ED75CBD1820@pgguru.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Mar 21, 2022, at 7:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> My impression is that there's not a lot of enthusiasm for the concept? If
>> that's true we maybe ought to mark the CF entry as rejected?
>
> Yeah, I'm kind of leaning that way too. I don't see how we can
> incorporate the symbolic values into any existing display paths
> without breaking applications that expect the old output.
> That being the case, it seems like we'd have "two ways to do it"
> indefinitely, which would add enough confusion that I'm not
> sure there's a net gain. In particular, I foresee novice questions
> along the lines of "I set foo to disabled, why is it showing
> as zero?"
Yeah, my main motivation here was about trying to have less special values in the config files, but I guess it would effectively be making everything effectively an enum and still relies on knowing just what the specific magic values are, no not really a net gain in this department.
For the record, I thought this would have a fairly low chance of getting in, was mainly curious what level of effort it would take to get something like this going and get some feedback on the actual idea.
> If we'd done it like this from the beginning, it'd have been
> great, but retrofitting it now is a lot less appealing.
Yeah, agreed on this. As far as I’m concerned we can reject.
Thanks,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-03-22 18:20:55 | Re: LockAcquireExtended() dontWait vs weaker lock levels than already held |
Previous Message | Robert Haas | 2022-03-22 18:04:11 | Re: pg14 psql broke \d datname.nspname.relname |