Making ParameterStatus available for more parameter types?

Started by Shay Rojanskyover 10 years ago2 messages
#1Shay Rojansky
roji@roji.org

Hi everyone.

The ParameterStatus message is currently sent for a hard-wired set of
parameters (
http://www.postgresql.org/docs/current/static/protocol-flow.html#PROTOCOL-ASYNC
).

Just wanted to let you know that making this more flexible would be a great
help in driver implementation. Npgsql maintains its own view of the current
statement_timeout parameter for various reasons; as long as the standard
ADO.NET API is used to change the timeout everything is OK, but if the user
ever manually sets statement_timeout things can become quite messy. Being
able to subscribe to more parameter changes would help in this case. In the
very short term simply adding statement_timeout to the hard-wired set would
help me as well.

Thanks,

Shay

#2Robert Haas
robertmhaas@gmail.com
In reply to: Shay Rojansky (#1)
Re: Making ParameterStatus available for more parameter types?

On Sun, Jul 12, 2015 at 5:30 AM, Shay Rojansky <roji@roji.org> wrote:

The ParameterStatus message is currently sent for a hard-wired set of
parameters
(http://www.postgresql.org/docs/current/static/protocol-flow.html#PROTOCOL-ASYNC).

Just wanted to let you know that making this more flexible would be a great
help in driver implementation. Npgsql maintains its own view of the current
statement_timeout parameter for various reasons; as long as the standard
ADO.NET API is used to change the timeout everything is OK, but if the user
ever manually sets statement_timeout things can become quite messy. Being
able to subscribe to more parameter changes would help in this case. In the
very short term simply adding statement_timeout to the hard-wired set would
help me as well.

Requests to add more stuff to ParameterStatus messages are becoming a
somewhat regular thing around here. Your idea of giving the client
the ability to subscribe to the stuff it cares about might be a good
way forward, because sending more and more things all the time adds
overhead for all clients, even those that don't care.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers