Message-ID: <3E7BA003.9070501@xythos.com>
Date: Fri, 21 Mar 2003 15:28:03 -0800
From: Barry Lind <blind@xythos.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
	Alvaro Herrera <alvherre@dcc.uchile.cl>,
	PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [INTERFACES] Roadmap for FE/BE protocol redesign
References: <200303212252.h2LMqsF20161@candle.pha.pa.us>
In-Reply-To: <200303212252.h2LMqsF20161@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Bruce Momjian wrote:
> I was thinking if we had a SET PERMANENT that couldn't be changed,
> interfaces that want to control variables could set them perminantly,
> and others could let users control it.

SET PERMANENT only works for those variables that can only have one 
value for a given client protocol (for example datestyle in jdbc). 
Whereas autocommit needs to be changeable by the jdbc driver since the 
jdbc spec allows the user to call an API method to change the setting.

> 
> Actually, if we reported change to the client, the interface could
> override any change the user made --- just an idea.

Reporting the change to the client seems sufficient for the client to 
take whatever actions are necessary.

--Barry

> 
> ---------------------------------------------------------------------------
> 
> Tom Lane wrote:
> 
>>Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>
>>>Man, I lost another vote!  :-)
>>
>>Happens to us all ;-)
>>
>>But this discussion is far from over ... not that many people have
>>weighed in yet.  Also, even if autocommit's fate is sealed, we still
>>have to think about how to handle the other variables Barry identified
>>as trouble spots.
>>
>>			regards, tom lane
>>
> 
>