public inbox for [email protected]
help / color / mirror / Atom feeds/pg_attribute_always_inline/pg_always_inline/?
11+ messages / 6 participants
[nested] [flat]
* s/pg_attribute_always_inline/pg_always_inline/?
@ 2026-04-08 21:09 Andres Freund <[email protected]>
2026-04-08 21:30 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Geoghegan <[email protected]>
2026-04-09 00:00 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Eisentraut <[email protected]>
0 siblings, 2 replies; 11+ messages in thread
From: Andres Freund @ 2026-04-08 21:09 UTC (permalink / raw)
To: pgsql-hackers
Hi,
When reviewing the index prefetching patch I got a bit dismayed at how long
pg_attribute_always_inline is due to the way it triggers pgindent to format
stuff.
I propose that we remove the _attribute_ part of the name.
Given that it is implemented for compilers that don't use the
__attribute__((always_inline)) spelling, so the shorter name seems better
anyway.
Thoughts?
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: s/pg_attribute_always_inline/pg_always_inline/?
2026-04-08 21:09 s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
@ 2026-04-08 21:30 ` Peter Geoghegan <[email protected]>
1 sibling, 0 replies; 11+ messages in thread
From: Peter Geoghegan @ 2026-04-08 21:30 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers
On Wed, Apr 8, 2026 at 5:09 PM Andres Freund <[email protected]> wrote:
> When reviewing the index prefetching patch I got a bit dismayed at how long
> pg_attribute_always_inline is due to the way it triggers pgindent to format
> stuff.
I had to significantly reorder function prototypes to avoid overly
long prototypes that had pg_attribute_always_inline. While perhaps not
strictly necessary, we shouldn't have to work around the fact that
pg_attribute_always_inline is an absurdly verbose symbol name.
> I propose that we remove the _attribute_ part of the name.
+1
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: s/pg_attribute_always_inline/pg_always_inline/?
2026-04-08 21:09 s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
@ 2026-04-09 00:00 ` Peter Eisentraut <[email protected]>
2026-04-09 14:40 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
1 sibling, 1 reply; 11+ messages in thread
From: Peter Eisentraut @ 2026-04-09 00:00 UTC (permalink / raw)
To: Andres Freund <[email protected]>; pgsql-hackers
On 08.04.26 23:09, Andres Freund wrote:
> Hi,
>
> When reviewing the index prefetching patch I got a bit dismayed at how long
> pg_attribute_always_inline is due to the way it triggers pgindent to format
> stuff.
>
> I propose that we remove the _attribute_ part of the name.
>
> Given that it is implemented for compilers that don't use the
> __attribute__((always_inline)) spelling, so the shorter name seems better
> anyway.
Yes, and the existing name is also kind of wrong even on GCC because the
macro does not expand to only an attribute but also includes the "inline".
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: s/pg_attribute_always_inline/pg_always_inline/?
2026-04-08 21:09 s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-04-09 00:00 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Eisentraut <[email protected]>
@ 2026-04-09 14:40 ` Andres Freund <[email protected]>
2026-05-27 22:17 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Andres Freund @ 2026-04-09 14:40 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: pgsql-hackers
Hi,
On 2026-04-09 02:00:37 +0200, Peter Eisentraut wrote:
> On 08.04.26 23:09, Andres Freund wrote:
> > Hi,
> >
> > When reviewing the index prefetching patch I got a bit dismayed at how long
> > pg_attribute_always_inline is due to the way it triggers pgindent to format
> > stuff.
> >
> > I propose that we remove the _attribute_ part of the name.
> >
> > Given that it is implemented for compilers that don't use the
> > __attribute__((always_inline)) spelling, so the shorter name seems better
> > anyway.
>
> Yes, and the existing name is also kind of wrong even on GCC because the
> macro does not expand to only an attribute but also includes the "inline".
It didn't start out that way, that only came in a bit later, in
434e6e148441...
Created a CF entry, to reduce the chances of me forgetting about committing
this early in the 20 cycle.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: s/pg_attribute_always_inline/pg_always_inline/?
2026-04-08 21:09 s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-04-09 00:00 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Eisentraut <[email protected]>
2026-04-09 14:40 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
@ 2026-05-27 22:17 ` Peter Geoghegan <[email protected]>
2026-06-12 15:22 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Tomas Vondra <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Peter Geoghegan @ 2026-05-27 22:17 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-hackers; Tomas Vondra <[email protected]>
On Thu, Apr 9, 2026 at 10:40 AM Andres Freund <[email protected]> wrote:
> Created a CF entry, to reduce the chances of me forgetting about committing
> this early in the 20 cycle.
We already have a pg_noinline. How about renaming
pg_attribute_always_inline to pg_mustinline? That is an alternative
that is both consistent with pg_noinline, and even terser than your
proposal.
I have no intention of holding this patch up with bikeshedding. But I
noticed that even your proposed pg_always_inline rename still leaves
function prototypes over the column limit with moderately verbose
function names. It seems better to avoid that outcome.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: s/pg_attribute_always_inline/pg_always_inline/?
2026-04-08 21:09 s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-04-09 00:00 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Eisentraut <[email protected]>
2026-04-09 14:40 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-05-27 22:17 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Geoghegan <[email protected]>
@ 2026-06-12 15:22 ` Tomas Vondra <[email protected]>
2026-06-12 16:10 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Tomas Vondra @ 2026-06-12 15:22 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; Andres Freund <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-hackers
On 5/28/26 00:17, Peter Geoghegan wrote:
> On Thu, Apr 9, 2026 at 10:40 AM Andres Freund <[email protected]> wrote:
>> Created a CF entry, to reduce the chances of me forgetting about committing
>> this early in the 20 cycle.
>
> We already have a pg_noinline. How about renaming
> pg_attribute_always_inline to pg_mustinline? That is an alternative
> that is both consistent with pg_noinline, and even terser than your
> proposal.
>
I agree we should shorten pg_attribute_always_inline, it's way too
verbose. And other attributes don't include the _attribute_ either (like
the pg_noinline mentioned here).
I'm not sure about pg_mustinline. It seems weird to me, and I'm not sure
saving the 3 characters is worth it, pg_always_inline seems better.
> I have no intention of holding this patch up with bikeshedding. But I
> noticed that even your proposed pg_always_inline rename still leaves
> function prototypes over the column limit with moderately verbose
> function names. It seems better to avoid that outcome.
>
Yeah, we should not do such weird stuff just because of unnecessarily
long attribute names.
Question - do we plan to do this in master only, or was the plan to
backpatch the change? I'm not sure if these labels are used outside the
core code, that might be an issue for backpatching.
regards
--
Tomas Vondra
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: s/pg_attribute_always_inline/pg_always_inline/?
2026-04-08 21:09 s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-04-09 00:00 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Eisentraut <[email protected]>
2026-04-09 14:40 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-05-27 22:17 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Geoghegan <[email protected]>
2026-06-12 15:22 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Tomas Vondra <[email protected]>
@ 2026-06-12 16:10 ` Peter Geoghegan <[email protected]>
2026-07-08 21:41 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Tomas Vondra <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Peter Geoghegan @ 2026-06-12 16:10 UTC (permalink / raw)
To: Tomas Vondra <[email protected]>; +Cc: Andres Freund <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Fri, Jun 12, 2026 at 11:23 AM Tomas Vondra <[email protected]> wrote:
> I'm not sure about pg_mustinline. It seems weird to me, and I'm not sure
> saving the 3 characters is worth it, pg_always_inline seems better.
I'm not going to make a fuss about it.
> Yeah, we should not do such weird stuff just because of unnecessarily
> long attribute names.
Right. Basically, I don't want to be told that I must completely
change the order of function definitions because I used
pg_[attribute]_always_inline. It's just not reasonable to impose that
requirement on patch authors.
> Question - do we plan to do this in master only, or was the plan to
> backpatch the change? I'm not sure if these labels are used outside the
> core code, that might be an issue for backpatching.
I think that we should bite the bullet and backpatch. I count only 17
instances of pg_attribute_always_inline on the master branch.
Some extensions will no longer build against the backbranches if we go
this way. However, extension authors should find it easy to work
around this on an ad-hoc basis. They're going to have to work around
it sooner or later, so we might as well favor the new spelling.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: s/pg_attribute_always_inline/pg_always_inline/?
2026-04-08 21:09 s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-04-09 00:00 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Eisentraut <[email protected]>
2026-04-09 14:40 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-05-27 22:17 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Geoghegan <[email protected]>
2026-06-12 15:22 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Tomas Vondra <[email protected]>
2026-06-12 16:10 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Geoghegan <[email protected]>
@ 2026-07-08 21:41 ` Tomas Vondra <[email protected]>
2026-07-09 00:02 ` Re: s/pg_attribute_always_inline/pg_always_inline/? David Rowley <[email protected]>
2026-07-09 06:05 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Geoghegan <[email protected]>
0 siblings, 2 replies; 11+ messages in thread
From: Tomas Vondra @ 2026-07-08 21:41 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Andres Freund <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 6/12/26 18:10, Peter Geoghegan wrote:
> On Fri, Jun 12, 2026 at 11:23 AM Tomas Vondra <[email protected]> wrote:
>> I'm not sure about pg_mustinline. It seems weird to me, and I'm not sure
>> saving the 3 characters is worth it, pg_always_inline seems better.
>
> I'm not going to make a fuss about it.
>
>> Yeah, we should not do such weird stuff just because of unnecessarily
>> long attribute names.
>
> Right. Basically, I don't want to be told that I must completely
> change the order of function definitions because I used
> pg_[attribute]_always_inline. It's just not reasonable to impose that
> requirement on patch authors.
>
>> Question - do we plan to do this in master only, or was the plan to
>> backpatch the change? I'm not sure if these labels are used outside the
>> core code, that might be an issue for backpatching.
>
> I think that we should bite the bullet and backpatch. I count only 17
> instances of pg_attribute_always_inline on the master branch.
>
> Some extensions will no longer build against the backbranches if we go
> this way. However, extension authors should find it easy to work
> around this on an ad-hoc basis. They're going to have to work around
> it sooner or later, so we might as well favor the new spelling.
>
So, what shall we do about this? I've been looking at the v29 of the
index prefetching patch series, which is using this attribute in a bunch
of places. And that reminded me of this thread.
I guess we should just commit that, so unless someone objects soon I'll
just do that. ISTM the agreement is to backpatch this too.
regards
--
Tomas Vondra
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: s/pg_attribute_always_inline/pg_always_inline/?
2026-04-08 21:09 s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-04-09 00:00 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Eisentraut <[email protected]>
2026-04-09 14:40 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-05-27 22:17 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Geoghegan <[email protected]>
2026-06-12 15:22 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Tomas Vondra <[email protected]>
2026-06-12 16:10 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Geoghegan <[email protected]>
2026-07-08 21:41 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Tomas Vondra <[email protected]>
@ 2026-07-09 00:02 ` David Rowley <[email protected]>
2026-07-09 00:14 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Tom Lane <[email protected]>
1 sibling, 1 reply; 11+ messages in thread
From: David Rowley @ 2026-07-09 00:02 UTC (permalink / raw)
To: Tomas Vondra <[email protected]>; +Cc: Peter Geoghegan <[email protected]>; Andres Freund <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Thu, 9 Jul 2026 at 09:42, Tomas Vondra <[email protected]> wrote:
> So, what shall we do about this? I've been looking at the v29 of the
> index prefetching patch series, which is using this attribute in a bunch
> of places. And that reminded me of this thread.
>
> I guess we should just commit that, so unless someone objects soon I'll
> just do that. ISTM the agreement is to backpatch this too.
How about just backpatching the new macro and leaving the old one in
place back branches? There should be slightly less backpatching pain
that way, for us, and fewer merge issues for people maintaining forks
on existing versions.
David
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: s/pg_attribute_always_inline/pg_always_inline/?
2026-04-08 21:09 s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-04-09 00:00 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Eisentraut <[email protected]>
2026-04-09 14:40 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-05-27 22:17 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Geoghegan <[email protected]>
2026-06-12 15:22 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Tomas Vondra <[email protected]>
2026-06-12 16:10 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Geoghegan <[email protected]>
2026-07-08 21:41 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Tomas Vondra <[email protected]>
2026-07-09 00:02 ` Re: s/pg_attribute_always_inline/pg_always_inline/? David Rowley <[email protected]>
@ 2026-07-09 00:14 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 11+ messages in thread
From: Tom Lane @ 2026-07-09 00:14 UTC (permalink / raw)
To: David Rowley <[email protected]>; +Cc: Tomas Vondra <[email protected]>; Peter Geoghegan <[email protected]>; Andres Freund <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
David Rowley <[email protected]> writes:
> On Thu, 9 Jul 2026 at 09:42, Tomas Vondra <[email protected]> wrote:
>> I guess we should just commit that, so unless someone objects soon I'll
>> just do that. ISTM the agreement is to backpatch this too.
> How about just backpatching the new macro and leaving the old one in
> place back branches?
+1. Breaking valid code in released branches is unfriendly.
regards, tom lane
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: s/pg_attribute_always_inline/pg_always_inline/?
2026-04-08 21:09 s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-04-09 00:00 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Eisentraut <[email protected]>
2026-04-09 14:40 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-05-27 22:17 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Geoghegan <[email protected]>
2026-06-12 15:22 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Tomas Vondra <[email protected]>
2026-06-12 16:10 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Peter Geoghegan <[email protected]>
2026-07-08 21:41 ` Re: s/pg_attribute_always_inline/pg_always_inline/? Tomas Vondra <[email protected]>
@ 2026-07-09 06:05 ` Peter Geoghegan <[email protected]>
1 sibling, 0 replies; 11+ messages in thread
From: Peter Geoghegan @ 2026-07-09 06:05 UTC (permalink / raw)
To: Tomas Vondra <[email protected]>; +Cc: Andres Freund <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Wed, Jul 8, 2026 at 5:41 PM Tomas Vondra <[email protected]> wrote:
> So, what shall we do about this? I've been looking at the v29 of the
> index prefetching patch series, which is using this attribute in a bunch
> of places. And that reminded me of this thread.
>
> I guess we should just commit that, so unless someone objects soon I'll
> just do that. ISTM the agreement is to backpatch this too.
+1 to backpatching, along with a compatibility macro that supports the
original spelling on backbranches only.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~2026-07-09 06:05 UTC | newest]
Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-04-08 21:09 s/pg_attribute_always_inline/pg_always_inline/? Andres Freund <[email protected]>
2026-04-08 21:30 ` Peter Geoghegan <[email protected]>
2026-04-09 00:00 ` Peter Eisentraut <[email protected]>
2026-04-09 14:40 ` Andres Freund <[email protected]>
2026-05-27 22:17 ` Peter Geoghegan <[email protected]>
2026-06-12 15:22 ` Tomas Vondra <[email protected]>
2026-06-12 16:10 ` Peter Geoghegan <[email protected]>
2026-07-08 21:41 ` Tomas Vondra <[email protected]>
2026-07-09 00:02 ` David Rowley <[email protected]>
2026-07-09 00:14 ` Tom Lane <[email protected]>
2026-07-09 06:05 ` Peter Geoghegan <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox