Re: A bad behavior under autocommit off mode - Mailing list pgsql-hackers

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@candle.pha.pa.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.
>