Re: A bad behavior under autocommit off mode

Actually, looking at this email, having a SET that is unchangeable would
fix the issues with autocommit, datestyle, and client encoding for jdbc.

The basic issue is that certain interfaces want to set these parameters
as unchangeable, and that would allow this.

In fact, I can see value in a permanent SET ability in other cases --- I
can imagine administrators wanting SET log_statement to 'on', either in
postgresql.conf or per-user/db that _can't_ be changed by the user. We
could specify permanent in postgresql.conf via a special syntax, like
':='.

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

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

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