On Thu, 11 Jul 2019 at 10:06, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Jul 11, 2019 at 8:23 AM Dave Cramer <p...@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: > 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 da...@postgresintl.com www.postgresintl.com > >
