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.
True. I remember dealing with (or trying to deal with) that mess in BDR's DDL replication.
I guess the question becomes "what is required to to permit apps, clients or drivers to safely and efficiently cache mappings of object names to server side metadata".
E.g. if I have a non-schema-qualified relation name what server side help is needed to make it possible to safely cache its column names, column order, and column types? Or for a given function name, cache whether it's a function or procedure, its IN, INOUT and OUT parameter names, positions and types, etc?
You sensibly point out that being notified of search_path changes is not sufficient. It might still be useful.
We have comprehensive server-side cache invalidation support. I wonder if it's reasonable to harness that. Let clients request that we accumulate invalidations and deliver them on the wire to the client at the end of each statement, before ReadyForQuery, along with a backend-local invalidation epoch that increments each time we send invalidations to the client.
The problem is that the client would have to send the invalidation epoch along with each query so the server could tell it to flush its cache and retry if there were invalidations since the end of the last query.
None of that is likely to be pretty given that we've been unable to agree on any way to extend the protocol at client request.
Anyone have any ideas for "near enough is good enough" approaches or methods that'd work with some client assistance / extension support / etc?
