Re: A bad behavior under autocommit off mode
От | Barry Lind |
---|---|
Тема | Re: A bad behavior under autocommit off mode |
Дата | |
Msg-id | 3E7B8B8B.4010108@xythos.com обсуждение исходный текст |
Ответ на | Re: A bad behavior under autocommit off mode (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: A bad behavior under autocommit off mode
(Bruce Momjian <pgman@candle.pha.pa.us>)
Re: A bad behavior under autocommit off mode (Tom Lane <tgl@sss.pgh.pa.us>) Re: A bad behavior under autocommit off mode (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | 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. >
В списке pgsql-hackers по дате отправления: