Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)

On Thu, 11 Jul 2019 at 10:06, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Jul 11, 2019 at 8:23 AM Dave Cramer <pg(at)fastcrypt(dot)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:
>

Sure, of course

>
> 1. I don't really like putting 'guc' into an externally visible name;
> that's why I suggested 'report'.
>

sure, no problem

>
> 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.
>
> Well we haven't even established the connection. I don't really see a way
to find extensions
I thought about checking the available GUC's. I'll add that.

Thanks for your quick response

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com

>
>