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 по дате отправления: