On Fri, Nov 21, 2025 at 05:26:52PM -0500, Andrew Dunstan wrote:
> > I agree, of course, that we shouldn't
> > randomly sandwhich a bunch of disparate values into a single GUC --
> > several separate GUCs is better. However, what about a value that
> > intrinsically has some internal structure? We o
On Fri, Nov 21, 2025 at 5:26 PM Andrew Dunstan wrote:
> One of the things that bothers me a bit here is that we seem to be
> inventing a bunch of micro-languages to deal with structured GUC data.
> Maybe they could all be JSON?
I can understand why you (or anyone) would suggest this, but I don't
On 2025-11-18 Tu 2:56 PM, Robert Haas wrote:
In general, I don't think that whether or not a GUC's parsed value can
be serialized easily into a single palloc'd chunk is a good measure of
whether it's too complicated.
+1
I agree, of course, that we shouldn't
randomly sandwhich a bunch of
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