Re: [PATCH] Proof of concept for GUC improvements
От | David Christensen |
---|---|
Тема | Re: [PATCH] Proof of concept for GUC improvements |
Дата | |
Msg-id | E8E43736-060D-4FD2-BC4A-4ED75CBD1820@pgguru.net обсуждение исходный текст |
Ответ на | Re: [PATCH] Proof of concept for GUC improvements (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] Proof of concept for GUC improvements
|
Список | pgsql-hackers |
> On Mar 21, 2022, at 7:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Andres Freund <andres@anarazel.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 effectivelybe 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 wouldtake 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
В списке pgsql-hackers по дате отправления: