On Thu, Jul 11, 2019 at 10:11 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: > > 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. > > Gut reaction is that define_custom_variable would need to consult > the list to see if a newly-defined variable should be marked GUC_REPORT.
Yeah, that seems like a good idea. > Therefore, at least for qualified GUC names, we can't issue an error > for unrecognized names. But maybe it should complain about unrecognized > unqualified names. I had the same thought, but I just realized that's probably unfriendly: at the point when the client is assembling the list of names to send to the server, it doesn't know the server version. I think we're probably best off assuming that any names we don't recognize are something that got added in a newer server version and just ignoring them. The client is not powerless to sort this out after-the-fact: once the connection is made, they'll know the server version and also have the option to interrogate pg_settings if they wish. We also need to think about how to write a test for this patch... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
