Re: A bad behavior under autocommit off mode
От | Peter Eisentraut |
---|---|
Тема | Re: A bad behavior under autocommit off mode |
Дата | |
Msg-id | Pine.LNX.4.44.0303250914470.1651-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: A bad behavior under autocommit off mode (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: A bad behavior under autocommit off mode
|
Список | pgsql-hackers |
Tom Lane writes: > We can perhaps get away with saying that for client_encoding, but what > of DateStyle? "SET" has been the traditional way to adjust that since > the stone age. The JDBC driver sets the datestyle on startup and there's no reason why a client application would explicitly want to change it to defeat the JDBC driver. So "don't do that" applies here as well. It could be helpful to have a command to set a value and not allow it to be changed afterwards. But are there *real* applications where it would make a difference? And where does it stop? There are about a dozen GUC variables that will break an application as a whole if they don't have the value expected by the application. Do we need to install guards against all of these? > It seems to me there is not a lot of distance between what I originally > suggested (transmit values of interesting variables at connection start) > and what we're talking about here (transmit values of interesting > variables at connection start and then again if they change). I thought the originally proposed transmission was from the client to the server (client encoding, time zone) whereas this transmission would be from the server to the client. -- Peter Eisentraut peter_e@gmx.net
В списке pgsql-hackers по дате отправления: