Re: Proposal to add GUC_REPORT to lc_monetary, lc_numeric and search_path

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+QHhqCwrAA@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 <roji(at)roji(dot)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.
>
>