From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: IWYU annotations |
Date: | 2025-01-15 19:21:04 |
Message-ID: | f23328bb-f3d8-4db9-9787-4f7a875d8520@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10.01.25 09:10, Peter Eisentraut wrote:
> On 02.01.25 17:15, Tom Lane wrote:
>>> It's a fair point that some documentation could be provided. I suppose
>>> we don't want to verbosely explain each pragma individually. Should
>>> there be some central explanation, maybe in src/tools/pginclude/README?
>>
>> That might do, but perhaps instead in the "PostgreSQL Coding
>> Conventions" chapter of the SGML docs? Actually, I think we could do
>> with a centralized explanation of our inclusion conventions --- I'm
>> not sure that the whole business of "postgres.h or a sibling must be
>> first" is explained in any easy-to-find place. This topic would
>> likely fit well with such an explanation.
>
> In this updated patch set, I've just added a bit of info into src/tools/
> pginclude/README. Updating the coding convention documentation like you
> suggest also sounds like a good idea, but from my perspective I would
> need to do further research to pin down what those actually are, so I'm
> leaving that as a separate project.
>
> (See for example the business in src/tools/pginclude/headerscheck about
> guessing which the appropriate first header file should be for each
> component. That kind of thing perhaps ought to be more formalized.)
>
>> But really, the point I was trying to make above is that I don't
>> want this to break our very long-standing convention that headers
>> should be #include'd alphabetically and there is never a need to
>> impose some other order (at least not without lots of commentary
>> about it at the scene of the crime). The way you've done it here
>> is just asking for trouble, IMO. If that means redundant pragma
>> commands, so be it.
>
> Yeah, that's a fair point. I have removed that part from my patch set.
I have committed this. Thanks for the feedback.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2025-01-15 19:21:08 | Re: convert libpgport's pqsignal() to a void function |
Previous Message | Alena Rybakina | 2025-01-15 19:18:56 | Re: Sample rate added to pg_stat_statements |