Re: [PATCH] Allow complex data for GUC extra.
| От | Robert Haas |
|---|---|
| Тема | Re: [PATCH] Allow complex data for GUC extra. |
| Дата | |
| Msg-id | CA+Tgmob7HJ3zdA-hzdhsjPR0MubY+vjVyu7U9gUnE7=yZOQxMw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] Allow complex data for GUC extra. (Bryan Green <dbryan.green@gmail.com>) |
| Ответы |
Re: [PATCH] Allow complex data for GUC extra.
|
| Список | pgsql-hackers |
On Fri, Dec 5, 2025 at 12:45 AM Bryan Green <dbryan.green@gmail.com> wrote: > I tried implementing a PG_TRY/PG_CATCH approach and it doesn't work. > The switch statement in set_config_with_handle() has multiple early > returns (parse failures, prohibitValueChange checks, etc.) that bypass > both the success path and the PG_CATCH handler. If we've switched into > extra_cxt before entering the switch, these early returns leave > CurrentMemoryContext pointing at a temp context. I'm pretty sure it's not intended that you can return out of a PG_CATCH() block. You could, however, modify the control flow so that you stash the return value in a variable and the actual return happens after you exit the PG_CATCH() block. But I also don't understand why you want to use a PG_CATCH() block here in the first place. At first glance, I'm inclined to wonder why this wouldn't be a new wrinkle for the existing logic in call_string_check_hook. > The check hook API would be: > > MemoryContext oldcxt = MemoryContextSwitchTo(extra_cxt); > /* allocate complex structures with palloc */ > MemoryContextSwitchTo(oldcxt); > *extra = my_data_pointer; > > Not as automatic as Robert's suggestion, but it avoids the early return > problem entirely. This wouldn't be terrible or anything, and someone may prefer it on stylistic grounds, but I don't really think I believe your argument that this is the only way it can work. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: