Re: [PATCH] Allow complex data for GUC extra.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bryan Green <dbryan(dot)green(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Allow complex data for GUC extra.
Date: 2025-12-05 20:48:32
Message-ID: CA+Tgmob7HJ3zdA-hzdhsjPR0MubY+vjVyu7U9gUnE7=yZOQxMw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 5, 2025 at 12:45 AM Bryan Green <dbryan(dot)green(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-12-05 20:52:40 Re: More const-marking cleanup
Previous Message Nathan Bossart 2025-12-05 20:47:38 Re: vacuumdb: add --dry-run