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

I wonder if we should allow the client to specify settings on connection
start that _can't_ be changed via SET.

---------------------------------------------------------------------------

Barry Lind wrote:
> 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.
> > 
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073