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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
