Alvaro Herrera writes:
> On 2022-Sep-12, Tom Lane wrote:
>> Yeah, I suspect people will have to manually reapply any changes in
>> the GUC tables to guc_tables.c. That'll be the same amount of work
>> for them whenever we commit this patch (unless theirs lands first,
>> in which case I have to de
On 2022-Sep-12, Tom Lane wrote:
> Yeah, I suspect people will have to manually reapply any changes in
> the GUC tables to guc_tables.c. That'll be the same amount of work
> for them whenever we commit this patch (unless theirs lands first,
> in which case I have to deal with it). The issue I thi
Hi,
On 2022-09-12 21:12:03 +0100, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane writes:
>
> >> I think this is localized enough that asking people to manually resolve a
> >> conflict around adding a GUC entry wouldn't be asking for that much. And I
> >> think plenty changes might be automatically r
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Git can detect more complicated code movement (see the `--color-moved`
> option to `git diff`), but I'm not sure it's clever enough to realise
> that a change modifying a block of code that was moved in the meanwhile
> should be applied at the ne
Tom Lane writes:
>> I think this is localized enough that asking people to manually resolve a
>> conflict around adding a GUC entry wouldn't be asking for that much. And I
>> think plenty changes might be automatically resolvable, despite the rename.
>
> I wonder whether git will be able to figur
Andres Freund writes:
> - a bit worried that in_hot_standby will be confusing due vs InHotStandby. I
> wonder if we could perhaps get rid of an underlying variable in cases where
> we really just need the GUC entry to trigger the show hook?
Yeah, that worried me too. We do need the variable
Hi,
On 2022-09-11 18:31:41 -0400, Tom Lane wrote:
> Here's a v3 that gets rid of guc_hooks.c in favor of moving the
> hook functions to related modules (though some did end up in
> variables.c for lack of a better idea).
- a bit worried that in_hot_standby will be confusing due vs InHotStandby. I
Here's a v3 that gets rid of guc_hooks.c in favor of moving the
hook functions to related modules (though some did end up in
variables.c for lack of a better idea). I also pushed all the
hook function declarations to guc_hooks.h. Unsurprisingly,
removal of guc.h #includes from header files led to
I wrote:
> Michael Paquier writes:
>> One part that I have found a bit strange lately about guc.c is that we
>> have mix the core machinery with the SQL-callable parts. What do you
>> think about the addition of a gucfuncs.c in src/backend/utils/adt/ to
>> split things a bit more?
> I might be w
Michael Paquier writes:
> One part that I have found a bit strange lately about guc.c is that we
> have mix the core machinery with the SQL-callable parts. What do you
> think about the addition of a gucfuncs.c in src/backend/utils/adt/ to
> split things a bit more?
I might be wrong, but I think
On Sat, Sep 10, 2022 at 03:04:59PM -0400, Tom Lane wrote:
> Before proceeding further, I wanted to ask for comments on a design
> choice that might be controversial. Even though I don't want to
> invent guc_hooks.c, I think we *should* invent guc_hooks.h, and
> consolidate all the GUC hook functio
I wrote:
> Andres Freund writes:
>> On 2022-09-10 15:04:59 -0400, Tom Lane wrote:
>>> $ size guc*o
>>> text data bss dec hex filename
>>> 13653 4 112 1376935c9 guc-file.o
>>> 54953 0 564 55517d8dd guc.o
>>> 6951 0 11270631b97 guc_h
Hi,
On 2022-09-10 12:15:33 -0700, Andres Freund wrote:
> On 2022-09-10 15:04:59 -0400, Tom Lane wrote:
> > As things stand here, we have:
> >
> > 1. guc.c: the core GUC machinery.
> > 2. guc_tables.c: the data arrays, and some previously-exposed constant
> > tables. guc_tables.h can now be consid
Andres Freund writes:
> On 2022-09-10 15:04:59 -0400, Tom Lane wrote:
>> $ size guc*o
>> text data bss dec hex filename
>> 13653 4 112 1376935c9 guc-file.o
>> 54953 0 564 55517d8dd guc.o
>> 69510 11270631b97 guc_hooks.o
>> 43570
Hi,
On 2022-09-10 15:04:59 -0400, Tom Lane wrote:
> Here's a WIP stab at the project Andres mentioned [1] of splitting up
> guc.c into smaller files.
Cool!
> As things stand here, we have:
>
> 1. guc.c: the core GUC machinery.
> 2. guc_tables.c: the data arrays, and
Here's a WIP stab at the project Andres mentioned [1] of splitting up
guc.c into smaller files. As things stand here, we have:
1. guc.c: the core GUC machinery.
2. guc_tables.c: the data arrays, and some previously-exposed constant
tables. guc_tables.h can now be considered the assoc
17 matches
Mail list logo
