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
