Re: get/setReadOnly broken if default_transaction_read_only on
От | Tom Lane |
---|---|
Тема | Re: get/setReadOnly broken if default_transaction_read_only on |
Дата | |
Msg-id | 11465.1339163239@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: get/setReadOnly broken if default_transaction_read_only on (Craig Ringer <ringerc@ringerc.id.au>) |
Ответы |
Re: get/setReadOnly broken if default_transaction_read_only on
|
Список | pgsql-jdbc |
Craig Ringer <ringerc@ringerc.id.au> writes: > On 06/08/2012 04:19 PM, Johann 'Myrkraverk' Oskarsson wrote: >> Craig Ringer<ringerc@ringerc.id.au> writes: >>> The JDBC driver really needs a way to grab everything it needs to know >>> efficiently during initial connection setup, with some extensibility >>> so connection parameters can specify other things to request and cache >>> when the connection is first established. > I was thinking more of running something like: > ... preferably combined with a mechanism for the server to notify (or > NOTIFY) the JDBC client when a pg_ctl reload or a SET causes settings to > change. Running pg_settings() seems like a dead end to me, precisely because you won't know about any subsequent changes; and most of the parameters that JDBC might care about are changeable. LISTEN/NOTIFY is not the answer either, for the reasons you mention as well as some others. There already is a mechanism to notify clients of changes in selected GUC settings, but currently the set of parameters so reported is hard-wired. Possibly pgsql-hackers would consider a proposal to let the GUC_REPORT flag get set on client-selected parameters. regards, tom lane
В списке pgsql-jdbc по дате отправления: