Re: Small bug on CREATE EXTENSION pgq...
| От | Jim Nasby | 
|---|---|
| Тема | Re: Small bug on CREATE EXTENSION pgq... | 
| Дата | |
| Msg-id | 54CAA92B.1010000@BlueTreble.com обсуждение исходный текст | 
| Ответ на | Re: Small bug on CREATE EXTENSION pgq... (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Список | pgsql-hackers | 
On 1/28/15 10:25 PM, Tom Lane wrote: > Stephen Frost <sfrost@snowman.net> writes: >> * David Johnston (david.g.johnston@gmail.com) wrote: >>> Fair enough but "reset" to what? I don't know the internal mechanics but >>> if the session default is "warning" and a local change sets it to "notice" >>> then an unconditional reset would not get us back to the intended value. > >> Yeah, we'd really want to reset it to "what it was before." > > An extension script runs as a single transaction, so SET LOCAL could've > been used to accomplish the result without trashing the session-lifespan > setting. > > I'm not sure whether or not there was good reason to be changing the > setting at all, but it's entirely on the extension script's head that > it didn't do this in a less invasive way. +1 One thing I have wished for is something akin to SET LOCAL that reverts at the end of a subtransaction. Typically I onlyneed to tweak something like client_min_messages for a single command, so I'd prefer to SAVEPOINT old_setting; SET LOCAL blah; command; RELEASE old_setting; -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: