Horton

Re: Mark all GUC variable as PGDLLIMPORT

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Julien Rouhaud <rjuju123@gmail.com>, Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-08-24T08:28:24Z
Lists: pgsql-hackers 
On 23.08.21 16:47, Julien Rouhaud wrote:
> On Mon, Aug 23, 2021 at 10:36 PM Bruce Momjian <bruce@momjian.us> wrote:
>>
>> So the problem is that extensions only _need_ to use that API on
>> Windows, so many initially don't, or that the API is too limited?
> 
> The inconvenience with that API is that it's only returning c strings,
> so you gave to convert it back to the original datatype.  That's
> probably why most of the extensions simply read from the original
> exposed variable rather than using the API, because they're usually
> written on Linux or similar, not because they want to mess up the
> stored value.

If there were an API, then in-core code should use it as well.

If, for example, an extension wanted to define a "float16" type, then it 
should be able to access extra_float_digits in the *same way* as 
float4out() and float8out() can access it.  This is clearly not possible 
today.

Commits

  1. Remove PGDLLIMPORT marker from __pg_log_level

  2. Mark a few 'bbsink' related functions / variables static.

  3. Add some missing PGDLLIMPORT markings

  4. Apply PGDLLIMPORT markings broadly.

  5. Helper script to apply PGDLLIMPORT markings.

  6. Simplify declaring variables exported from libpgcommon and libpgport.