Re: PG_TRY()/CATCH() in a loop reports uninitialized variables
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: PG_TRY()/CATCH() in a loop reports uninitialized variables |
| Дата | |
| Msg-id | 25875.1565275667@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | PG_TRY()/CATCH() in a loop reports uninitialized variables (Adam Lee <ali@pivotal.io>) |
| Список | pgsql-hackers |
Adam Lee <ali@pivotal.io> writes:
> That's fine actually, but if we put the PG_TRY()/CATCH() in a loop, high
> version gcc might complain.
I'd be inclined to say "so don't do that then". Given this interpretation
(which sure looks like a bug to me, gcc maintainers' opinion or no),
you're basically going to have to mark EVERYTHING in that function
volatile. Better to structure the code so you don't have to do that,
which would mean not putting the TRY and the loop in the same level
of function.
I've seen other weird-maybe-bug gcc behaviors in the vicinity of
setjmp calls, too, which is another factor that pushes me not to
want to assume too much about what you can do in the same function
as a TRY call.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера