Обсуждение: remove pg_restrict workaround

When in C11 mode, MSVC supports the standard "restrict" keyword, so we 
don't need the workaround with using "pg_restrict" instead anymore. 
(Just for clarification, restrict is a C99 feature, but MSVC only 
accepts it properly in C11 mode.)  So I'm proposing to remove that 
workaround here, so that code can use the standard restrict keyword 
without having to worry about the alternative spelling.

However, "restrict" does not exist in C++, but all supported compilers 
support the spelling "__restrict" in C++.  Therefore, I'm leaving in 
place the Autoconf test and the equivalent Meson business, to maintain 
the status quo with respect to C++.  I'm updating the comments about 
that a bit.  (In a C++-free world, we could have plausibly removed the 
Autoconf test altogether.)

While making the required adjustments, I found a few pieces of code that 
use restrict (previously pg_restrict) in what appears to me to be 
nonsensical ways, like

memcpy((char *pg_restrict) (buf->data + buf->len), &ni, sizeof(uint16));

The restrict qualifier is not meaningful in casts, so I'm confused about 
why it is used here.  I did not find any indications either in the old 
discussions leading up to this change or on the wider web that there are 
any other interpretations or compiler extensions or perhaps a C++ angle 
that would make this meaningful.  Also, the generated code appears to be 
the same if I remove this.  So I'm proposing to remove redundant casts 
like this.

Peter Eisentraut <peter@eisentraut.org> writes:
> When in C11 mode, MSVC supports the standard "restrict" keyword, so we 
> don't need the workaround with using "pg_restrict" instead anymore. 
> (Just for clarification, restrict is a C99 feature, but MSVC only 
> accepts it properly in C11 mode.)  So I'm proposing to remove that 
> workaround here, so that code can use the standard restrict keyword 
> without having to worry about the alternative spelling.

Won't this break extensions that are using pg_restrict?  Sure, they
could update their code, but then maybe it wouldn't work anymore
against previous branches.  Seems like it'd be better to leave
pg_restrict in place (for awhile anyway) but always #define it
as "restrict".  I don't mind ceasing to use it within our own tree
though.

            regards, tom lane

On 15.10.25 15:58, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> When in C11 mode, MSVC supports the standard "restrict" keyword, so we
>> don't need the workaround with using "pg_restrict" instead anymore.
>> (Just for clarification, restrict is a C99 feature, but MSVC only
>> accepts it properly in C11 mode.)  So I'm proposing to remove that
>> workaround here, so that code can use the standard restrict keyword
>> without having to worry about the alternative spelling.
> 
> Won't this break extensions that are using pg_restrict?  Sure, they
> could update their code, but then maybe it wouldn't work anymore
> against previous branches.  Seems like it'd be better to leave
> pg_restrict in place (for awhile anyway) but always #define it
> as "restrict".  I don't mind ceasing to use it within our own tree
> though.

Committed with a backward compatibility define.