Tom Lane wrote:
> 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.
>
The issues I was raising are more theoretical than practical. The only
reason I was raising them, is that while we are looking at changes to
the FE/BE protocol we should look at all the issues. Good general
purpose mechanisms (like what Tom is suggesting below) can be created
when a better understanding of all the issues is known.
--Barry
> 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 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
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
