| От | Hiroshi Inoue |
|---|---|
| Тема | Re: timeout implementation issues |
| Дата | |
| Msg-id | 3CBF6284.B36ABC5A@tpf.co.jp обсуждение исходный текст |
| Ответ на | Re: timeout implementation issues (Bruce Momjian <pgman@candle.pha.pa.us>) |
| Список | pgsql-hackers |
Tom Lane wrote: > > Hiroshi Inoue <Inoue@tpf.co.jp> writes: > > I don't think this is *all* *should be* or *all > > or nothing* kind of thing. If a SET variable has > > its reason, it would behave in its own right. > > Well, we could provide some kind of escape hatch to let the behavior > vary from one variable to the next. But can you give any specific > examples? Which SET variables should not roll back on error? It seems veeery dangerous to conclude that SET *should* roll back even if there's no *should not* roll back case. There could be no *should not* roll back case because a user could set the variable as he likes in the next transaction. Hiroshi Inouehttp://w2422.nsk.ne.jp/~inoue/
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера