After further thought about this, I concluded that a much better idea
is to just exclude fmgrprotos.h from the pgindent run. While renaming
these two functions may or may not be worthwhile, it doesn't provide
any sort of permanent fix for fmgrprotos.h, because new typedef conflicts
could arise at
Daniel Gustafsson writes:
>> On 21 Sep 2020, at 20:55, Tom Lane wrote:
>> Here's a proposed patch to fix it that way.
> +1 on this patch. Do you think it's worth adding a note about this in the
> documentation to save the next one staring at this a few minutes? Something
> along the lines of:
> On 21 Sep 2020, at 20:55, Tom Lane wrote:
>
> Oh wait, I forgot about the fmgrprotos.h discrepancy.
>
> I wrote:
>> It strikes me that a low-cost workaround would be to rename these
>> C functions. There's no law that their C names must match the
>> SQL names.
>
> Here's a proposed patch to
On 2020-Sep-21, Tom Lane wrote:
> > ... isn't this more likely to create a typedef entry than merely a
> > function name?
>
> Well, yeah, it *is* a typedef. My proposal is to rename the C function
> to avoid the conflict, rather than renaming the typedef. Given the
> small number of direct call
Alvaro Herrera writes:
> On 2020-Sep-21, Tom Lane wrote:
>> Here's a proposed patch to fix it that way.
> pgtypes_numeric.h still contains
> typedef struct
> {
> } numeric;
> ... isn't this more likely to create a typedef entry than merely a
> function name?
Well, yeah, it *is* a typedef. My p
On 2020-Sep-21, Tom Lane wrote:
> Oh wait, I forgot about the fmgrprotos.h discrepancy.
>
> I wrote:
> > It strikes me that a low-cost workaround would be to rename these
> > C functions. There's no law that their C names must match the
> > SQL names.
>
> Here's a proposed patch to fix it that
Oh wait, I forgot about the fmgrprotos.h discrepancy.
I wrote:
> It strikes me that a low-cost workaround would be to rename these
> C functions. There's no law that their C names must match the
> SQL names.
Here's a proposed patch to fix it that way.
regards, tom lane
> On 21 Sep 2020, at 19:59, Tom Lane wrote:
>
> I wrote:
>> We still have to deal with
>> src/backend/utils/sort/qsort_tuple.c
>> src/pl/plpgsql/src/plerrcodes.h
>> src/pl/plpython/spiexceptions.h
>> src/pl/tcl/pltclerrcodes.h
>> if we want to be entirely clean about this.
>
> I took care of tho
I wrote:
> We still have to deal with
> src/backend/utils/sort/qsort_tuple.c
> src/pl/plpgsql/src/plerrcodes.h
> src/pl/plpython/spiexceptions.h
> src/pl/tcl/pltclerrcodes.h
> if we want to be entirely clean about this.
I took care of those, so I think we're done here.
reg
I went ahead and added SPI.c, Util.c, and the *kwlist_d.h headers
to the exclusion list. I then tried to run pgindent in a completely
built-out development directory (not distclean'ed, which is the way
I'd always used it before). This found a few more exclusions we
need to have if we want to allo
Daniel Gustafsson writes:
>>> On that note, I
>>> wonder if we should add the plperl .xs generated files as exclusions too
>>> since
>>> we don't control that generator?
>> Not an issue I don't think; pgindent won't touch extensions other than
>> .c and .h.
> Sorry for being unclear, I meant th
>>> The attached patch fixes the generation of sql_help.h and perl_opmask.h to
>>> make
>>> sure they conform to pgindent. Those were the only file I got diffs in
>>> after a
>>> pgindent run apart from fmgrprotos.h which gave the below:
>
>> Hmm, I seem to recall there were more when this happ
Alvaro Herrera writes:
> On 2020-Sep-16, Tom Lane wrote:
>> I think the issue is that pgindent believes "numeric" and "chr" are
>> typedefs. (The regex code can be blamed for "chr", but I'm not quite
>> sure where "numeric" is coming from.)
> It's in src/interfaces/ecpg/include/pgtypes_numeric.h
I wrote:
> Daniel Gustafsson writes:
>> The attached patch fixes the generation of sql_help.h and perl_opmask.h to
>> make
>> sure they conform to pgindent. Those were the only file I got diffs in
>> after a
>> pgindent run apart from fmgrprotos.h which gave the below:
> Hmm, I seem to recall
On 2020-Sep-16, Tom Lane wrote:
> Daniel Gustafsson writes:
> > Not sure what pgindent is doing there, but it seems hard to address in the
> > generator.
>
> I think the issue is that pgindent believes "numeric" and "chr" are
> typedefs. (The regex code can be blamed for "chr", but I'm not qui
Daniel Gustafsson writes:
> The attached patch fixes the generation of sql_help.h and perl_opmask.h to
> make
> sure they conform to pgindent. Those were the only file I got diffs in after
> a
> pgindent run apart from fmgrprotos.h which gave the below:
Hmm, I seem to recall there were more wh
> On 22 May 2020, at 11:29, Peter Eisentraut
> wrote:
> On 2020-05-20 15:56, Tom Lane wrote:
>> I wonder if we should make an effort to ensure
>> that our generated .h and .c files always satisfy pgindent.
>
> We should generally try to do that, if only so that they don't appear weird
> and ra
On 2020-05-20 15:56, Tom Lane wrote:
On a closely related point: I was confused for awhile on Monday
afternoon, wondering why the built tarballs didn't match my local
tree. I eventually realized that when I'd run pgindent on Saturday,
it had reformatted some generated files such as
src/bin/psql/
Peter Eisentraut writes:
> If I run pgindent on a built tree on macos, I get this error
> Failure in ./src/backend/utils/probes.h: Error@375: Stuff missing from
> end of file
> The file in question is built by the dtrace command. I have attached it
> here.
> Is this something to fix in pgindent
> On 20 May 2020, at 11:52, Peter Eisentraut
> wrote:
> Or should this file be excluded, since it's generated?
That would get my vote. Generated files where we don't control the generator
can be excluded.
cheers ./daniel
20 matches
Mail list logo
