I don't really care which one gets implemented, although I think the latter makes more sense.
Dave Cramer
On Fri, 5 Jul 2019 at 08:05, Shay Rojansky <roji@roji.org> wrote:
> The latter is important for similar reasons. JDBC caches prepared statements internally and if the user changes the search path without using setSchema or uses a function to change it then internally it would be necessary to invalidate the cache. Currently if this occurs these statements fail.
While Npgsql specifically doesn't care about any locale/formatting (being a binary-only driver), knowing about search_path changes would benefit Npgsql in the same way as it would JDBC.
> This seems like a rather innocuous change as the protocol is not changed, rather the amount of information returned on startup is increased marginally.
Although adding these specific parameters are easy to add, we could also think of a more generic way for clients to subscribe to parameter updates (am not sure if this was previously discussed - I cannot see anything obvious in the wiki TODO page). At its simplest, this could be a new parameter containing a comma-separated list of parameters for which asynchronous updates should be sent. This new parameter would default to the current hard-coded list (as documented in https://www.postgresql.org/docs/current/protocol-flow.html#PROTOCOL-ASYNC). Unless I'm mistaken, one issue (as in general with new parameters) is that drivers wouldn't be able to send this new parameter in the startup package because they don't yet know whether they're talking to a PostgreSQL version which supports it.
