Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)
От | Robert Haas |
---|---|
Тема | Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status) |
Дата | |
Msg-id | CA+TgmoaWFKF1h__VP275MSBTOoOH6hrD33TtYSknG2nGORVEfg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status) (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)
Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status) |
Список | pgsql-hackers |
On Thu, Jul 11, 2019 at 8:23 AM Dave Cramer <pg@fastcrypt.com> wrote: > See attached for an initial patch. If this is an acceptable way to go I will add tests and documentation And clean up the code? Doesn't look crazy on a quick glance but I think I see at least half a dozen coding style problems. More substantively: 1. I don't really like putting 'guc' into an externally visible name; that's why I suggested 'report'. 2. I haven't really scrutinized whether what SetConfigReport is an OK way of implementing this. That probably needs some study. It may be fine. 3. I'm not sure that just ignoring any GUCs we don't find is the right thing. I'm also not sure that it's the wrong thing, but it might be. My question is: what if there's an extension-owned GUC in play? The library probably isn't even loaded at this stage, unless it's in shared_preload_libraries. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: