Tom Lane wrote:
> I'm not convinced that it's worth the trouble to make the set of
> reported variables be configurable on-the-fly as Bruce was suggesting.
> client_encoding and datestyle are candidates to send this way, but are
> there really others?
Well, let's look at this from a long term perspective. How likely is
it that a new development in the server will require additional
monitoring on the client side?
As an example, in the discussion about tracking transaction state, I
haven't seen any mention of nested transactions, but I suspect that at
least some clients (or their libraries) will be interested in the
current transaction nesting level.
What about savepoints? Is this something that the client side is
going to have any interest in? I wouldn't want to dismiss that
possibility entirely.
Other features that we develop in the future may be things the client
side is going to be interested in monitoring somehow, too.
Here's where I'm going with this: because the needs of the client
libraries are not set in stone for all time, and may even vary
significantly depending on the client (the needs of pgadmin probably
differ considerably from the needs of libpq, for instance), it seems
to me that what we really need is a *general* mechanism for making it
possible for the client to define what information it's interested in.
In this case, what we're really talking about is a general monitoring
function.
So: the most sensible course of action seems, to me, to be to provide
a mechanism to let the client notify the server that it should monitor
the state of some variable, and the server should send a NOTICE (or
some other kind of notification) to the client whenever the variable
changes. If the SQL standard doesn't define a command for this, we'll
have to define our own (something like "WATCH <variable> ON|OFF" or
something...I'm sure someone can come up with a much nicer syntax than
that but you get the point).
> A point that would have to be considered is what to do when a SET
> operation is rolled back by transaction abort. I think what we'd need
> to do is retransmit each time the effective value changes; so it'd
> work like this:
>
> -- initial DateStyle is foo
> BEGIN;
> SET DateStyle TO bar;
> -- backend sends status message showing DateStyle = bar
> SELECT ...
> -- reported dates will use DateStyle bar
> ROLLBACK;
> -- backend sends status message showing DateStyle = foo
Yes...whenever the watched variable changes from the perspective of
the client, the change notice should be sent to the client.
--
Kevin Brown kevin@sysexperts.com
