From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Shay Rojansky <roji(at)roji(dot)org> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Making ParameterStatus available for more parameter types? |
Date: | 2015-07-15 14:14:20 |
Message-ID: | CA+TgmoZNjbjgEF++HBMd9FG-Kpk98g=GHOPORZEHYTKx7BgWsg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jul 12, 2015 at 5:30 AM, Shay Rojansky <roji(at)roji(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2015-07-15 14:24:26 | Re: Implementation of global temporary tables? |
Previous Message | Simon Riggs | 2015-07-15 14:05:41 | Re: Implementation of global temporary tables? |