Обсуждение: BUG #19450: Where is checksum_block.inc.c after master install?

The following bug has been logged on the website:

Bug reference:      19450
Logged by:          RekGRpth
Email address:      rekgrpth@gmail.com
PostgreSQL version: 18.3
Operating system:   docker alpine
Description:

There is no checksum_block.inc.c after master install

On Sun, Apr 5, 2026 at 8:40 PM PG Bug reporting form
<noreply@postgresql.org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference:      19450
> Logged by:          RekGRpth
> Email address:      rekgrpth@gmail.com
> PostgreSQL version: 18.3
> Operating system:   docker alpine
> Description:
>
> There is no checksum_block.inc.c after master install

I'll look into that. What broke, so I can reproduce?

BTW, the bug reporting form is meant for released versions, and this
does not affect 18.3.

--
John Naylor
Amazon Web Services

John Naylor <johncnaylorls@gmail.com> writes:
>> There is no checksum_block.inc.c after master install

> I'll look into that. What broke, so I can reproduce?

src/include/Makefile knows what it's supposed to install out
of that subtree, and it thinks storage/*.h is sufficient.
I didn't check to see if the meson system has the same oversight.

One could argue that the real bug is having put a .c file into
the include/ tree in the first place.  Why was it done like that?
Couldn't it be a .h file?

            regards, tom lane

On Mon, Apr 6, 2026 at 9:50 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> src/include/Makefile knows what it's supposed to install out
> of that subtree, and it thinks storage/*.h is sufficient.
> I didn't check to see if the meson system has the same oversight.
>
> One could argue that the real bug is having put a .c file into
> the include/ tree in the first place.  Why was it done like that?
> Couldn't it be a .h file?

That was the way it was first coded. I thought of this way to avoid
adding an exception to headerscheck. I can reverse that decision
easily, but I may not get to it today.

--
John Naylor
Amazon Web Services

John Naylor <johncnaylorls@gmail.com> writes:
> On Mon, Apr 6, 2026 at 9:50 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> One could argue that the real bug is having put a .c file into
>> the include/ tree in the first place.  Why was it done like that?
>> Couldn't it be a .h file?

> That was the way it was first coded. I thought of this way to avoid
> adding an exception to headerscheck. I can reverse that decision
> easily, but I may not get to it today.

Ah, the good ol' law of conservation of cruft.  But on the whole
I think naming it .h not .c is less crufty.  Agreed that there's
no great urgency about changing it.

            regards, tom lane

On Mon, Apr 6, 2026 at 10:07 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> John Naylor <johncnaylorls@gmail.com> writes:
> > On Mon, Apr 6, 2026 at 9:50 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> One could argue that the real bug is having put a .c file into
> >> the include/ tree in the first place.  Why was it done like that?
> >> Couldn't it be a .h file?
>
> > That was the way it was first coded. I thought of this way to avoid
> > adding an exception to headerscheck. I can reverse that decision
> > easily, but I may not get to it today.
>
> Ah, the good ol' law of conservation of cruft.  But on the whole
> I think naming it .h not .c is less crufty.  Agreed that there's
> no great urgency about changing it.

Okay, done that way as of commit 8c3e22a8f.

--
John Naylor
Amazon Web Services