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

Hi,

On 2019-10-08 23:57:24 +0800, Craig Ringer wrote:
> In other places I've (ab)used GUC_REPORT to push information back to the
> client as a workaround for the lack of protocol extensibility / custom
> messages. It's a little less ugly than abusing NOTICE messages. I'd prefer
> a real way to add optional/extension messages, but in the absence of that
> extension-defined GUCs may have good reasons to want to report multiple
> changes within a single statement/function/etc.

FWIW, custom messages strike me as a terrible idea leading to a lot of
poorly thought ought extensions that various drivers have to implement,
without there being an authoritative source of what needs to be
implemented from a practical point of view.

> BTW, a good argument for the client wanting to be notified of search_path
> changes might be for clients that want to cache name=>oid mappings for
> types, relations, etc. The JDBC driver would be able to benefit from that
> if it could trust that the same name would map to the same type (for a
> top-level statement) in future, but currently it can't.

Unless schema qualified you can't rely on that even without search_path
changing. Consider an object in schema b existing, with a search_path of
a,b. Even without the search path changing, somebody could create a type
in a, "masking" the one in b. I'm somewhat convinced that search_path
has no role in this type of caching, unless you want to do it
wrong. There's a separate issue of needing cache invalidation for such
caches to cover some edge cases, but that's unrelated to search_path
imo.

Greetings,

Andres Freund