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

On Thu, 10 Oct 2019 at 23:45, Andres Freund <andres(at)anarazel(dot)de> wrote:

>
> 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?

--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise