On Tue, Nov 18, 2025 at 1:21 PM Tom Lane wrote:
> I'm really still dubious that this entire project is worthwhile.
> I think it is basically building support for GUCs whose values
> are unreasonably complicated, and would be better off if they
> got redesigned. Also, right now might be a bad time
Bryan Green writes:
> On 11/18/2025 11:24 AM, Robert Haas wrote:
>> A whole different way of doing this would be to make the GUC machinery
>> responsible for spinning up and tearing down the contexts. Then, the
>> check hook could just be called with CurrentMemoryContext already set
>> to the new
On 11/18/2025 11:24 AM, Robert Haas wrote:
> On Mon, Nov 17, 2025 at 4:17 PM Bryan Green wrote:
>> The solution uses a wrapper struct (GucContextExtra) containing both the
>> MemoryContext and data pointers. Check hooks:
>> 1. Create a context under CurrentMemoryContext (for error safety)
>> 2
On Mon, Nov 17, 2025 at 4:17 PM Bryan Green wrote:
> The solution uses a wrapper struct (GucContextExtra) containing both the
> MemoryContext and data pointers. Check hooks:
> 1. Create a context under CurrentMemoryContext (for error safety)
> 2. Allocate their data structures within it
> 3.
Following up on Tom Lane's suggestion to use MemoryContexts for GUC
extra data [1], I've implemented a working solution that addresses the
design issues Robert Haas identified with my initial approach.
The original problem: GUC check hooks can only return a single chunk for
extra data, making it
