Proposal to add GUC_REPORT to lc_monetary, lc_numeric and search_path

From: Dave Cramer <davecramer(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Shay Rojansky <roji(at)roji(dot)org>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, brian(dot)m(dot)carlson(at)gmail(dot)com
Subject: Proposal to add GUC_REPORT to lc_monetary, lc_numeric and search_path
Date: 2019-07-04 18:56:54
Message-ID: CADK3HHK6RimOQYPDgFWPYWiD5TH_XECgV=yJOv+h9kfzT55P7A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

The first 2 lc_monetary and lc_numeric are useful if the client for some
reason executes set lc_*. We don't get a report and in many cases can't
continue to parse numerics or money.
Now it it possible to get these at startup by issuing show or querying the
catalog, but it seems much cleaner to just send them.

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.

This seems like a rather innocuous change as the protocol is not changed,
rather the amount of information returned on startup is increased
marginally.

I've included the authors of the npgsql and the node drivers in the email
for their input.

Dave Cramer

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jose Luis Tallon 2019-07-04 22:08:16 Re: [PATCH] Implement uuid_version()
Previous Message Dent John 2019-07-04 18:44:42 Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead