See attached patch. I think adding GUC_REPORT to search_path is probably the most important as this is potentially a security issue. See joe conway's blog on security and search path here https://info.crunchydata.com/blog/postgresql-defaults-and-impact-on-security-part-2
I also see there was a proposal to make reportable GUC's configurable here https://www.postgresql.org/message-id/ca+tgmobsxsy0kfr_vdqqoxjxqafnesfxf_-darne+qhhqcw...@mail.gmail.com 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 <r...@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. > >
0001-make-lc_monetary-lc_numeric-and-search_path-GUC_REPO.patch
Description: Binary data
