Barry Lind <blind@xythos.com> writes:
> In the previous email I discusses why autocommit perhaps shouldn't be a
> GUC parameter. From a jdbc perspective what was said in that email
> generally applies to client_encoding and datestyle as well.
Hmm. I'm not sure that it makes sense for clients to want to change
client_encoding on the fly, but it's harder to make that claim for
datestyle. And datestyle has been a SET variable for so long that we
would get a *lot* of compatibility flak if we took it away.
I had originally been thinking of reporting client_encoding as a field
of some message sent only at backend startup. However, what if we send
such a message whenever one of the variables it includes changes?
(This is basically Bruce's idea from last night, but refined to only
send the data when it changes, rather than on every query; that should
eliminate the bandwidth-wastage objection.)
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?
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 fooBEGIN;SET DateStyle TO bar;-- backend sends status message showing DateStyle = barSELECT
...--reported dates will use DateStyle barROLLBACK;-- backend sends status message showing DateStyle = foo
regards, tom lane
