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

From Tom Lane
Subject Re: A bad behavior under autocommit off mode
Date
Msg-id 1639.1048354766@sss.pgh.pa.us
Whole thread Raw
In response to Re: A bad behavior under autocommit off mode  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: A bad behavior under autocommit off mode  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> I'm not sure they need these parameters to be *unchangeable*.  What they
>> need is to *know what they are*, with certainty.  The notion of issuing
>> an automatic report message whenever the values change would seem to
>> answer that.

> What concerns me also about the reporting problem is that some of these
> interfaces must issue queries in several places in the code, so somehow
> they have to make sure they check for those _special_ values in all
> those places.

Not sure what your point is here.  If an interface is going to support
more than one value of a parameter, then yes it has to be sure to do the
right thing in each affected place.  There's no shortcut for that.

> Also, with autocommit, is the idea for autocommit logic to be in the
> clients, or just control of autocommit to be in the clients, with the
> logic still being in the server?

My thought is to put it in the clients.  All except libpq already have
some such logic, and it worked well enough except for their inability to
be completely sure of the backend's state --- which we will fix with the
protocol revision.  The server-side implementation has turned out to be
a complete mess.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: A bad behavior under autocommit off mode
Next
From: Bruce Momjian
Date:
Subject: Re: A bad behavior under autocommit off mode