Re: A bad behavior under autocommit off mode

Currently the four variables that the jdbc driver would like to know
about are (However pending other changes in 7.4, some or all of these
may no longer be necessary):

trx state
autocommit
client_encoding
datestyle

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. The client
protocol (jdbc in this case) determines how it wants to communicate with
the server. It isn't really the system administrator or an end user SET
that should determine that. In the jdbc case if the user were to issue
a SET to change the client_encoding bad things would happen since the
driver would no longer know how to correctly encode/decode information
to/from the server. Likewise if the datestyle where changed, the driver
wouldn't know how to parse the dates coming over the FE/BE protocol in
order to create native java Date objects.

Now how important is this problem? Not very IMHO. I raise it only for
discussion. Over the last three years I have been involved with the
postgres jdbc driver, I can't remember anyone ever complaining that they
issued a SET and then the driver didn't work anymore. That is probably
because in general it doesn't make sense for the end user to be changing
these settings, even though the GUC funcionality allows them to do that.

The setting of datestyle impacts the over the wire format for dates. In
general I think it is a bad idea for the FE/BE protocol to be impacted
by user and administrator decisions. Just because you want dates in
psql to show one way, doesn't mean that all client protocols should have
to deal with that.

If you look at datestyle, autocommit and probably client_encoding as
well, they provide useful functionality to users of psql, but cause work
for everyone else. They probably should have been implemented as
features of psql (with backend support where needed) instead of
impacting the overall FE/BE protocol.

thanks,
--Barry

Bruce Momjian wrote:
> Tom Lane wrote:
>
>>Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>>
>>>Tom, did you have any thought of adding the ability to ask for reports
>>>on GUC variables on every query return?
>>
>>That seems excessive. There is a case for reporting autocommit (if
>>we don't decide to remove it altogether, which is still an open
>>argument). I have not heard any complaints suggesting that we need any
>>others.
>
>
> Well, the jdbc guys like SET, and I haven't seen any proposal that
> explains how applications would control a client-based autocommit API
> from the client.
>
>
>>A fixed commitment to report xact status will cost us one byte added to
>>Z messages. If we add a commitment to report autocommit status, we
>>could choose to pack that bit into the same byte as xact status (still
>>only three bits used...). A slightly more forward-looking approach
>>would be to decree that Z messages carry labeled status bytes, ie, pairs
>>of <label> <status> bytes, which makes total cost 4 bytes to transmit
>>xact state and autocommit state. But if we want to say that we'll
>>transmit *any* darn random GUC variable you want to hear about, I don't
>>think we can use a compact encoding of this sort; instead we're talking
>>about sending the whole GUC variable name and string value as label and
>>value. In other words the Z message starts to look like
>> Z X a c t s t a t u s \0 i d l e \0 a u t o c o m m i t \0 o f f \0
>>and somewhere around here my concern for connection bandwidth kicks in.
>>A 10X increase in bytes sent is a bit much to cater to hypothetical
>>needs.
>
>
> Very true. The only other environment variable I have heard about was
> client encoding. As I remember right now, we do have a problem with SET
> changing the client encoding, and the client not realizing that.
>
> My idea may be overdesign.
>