GUC variables invisible to contrib/ modules under Win32

Mark Cave-Ayland wrote:

Under Linux, PostGIS compiles and links fine without any trouble.
However, when compiling under Win32 we get the following message:

Info: resolving _default_statistics_target by linking to
__imp__default_statistics_target (auto-import)
fu000024.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname'
nmth000023.o(.idata$4+0x0): undefined reference to
`_nm__default_statistics_target'
c:\mingw\bin\dllwrap.exe: c:\mingw\bin\gcc exited with status 1

The current "fix" to enable this to work correctly is to change the
relevant line in /src/include/commands/vacuum.h from "extern int
default_statistics_target;" to "extern DLLIMPORT int
default_statistics_target;". However, I'm not convinced this is the
correct fix given that other contrib modules may require access to other
GUC variables.

It would be fine if all non-static variables would be defined
extern DLLIMPORT, but since non-backend modules don't regularly access
those variables most won't have that keyword. Additionally, this is yet
another M$ issue, non-existent anywhere else.

A work around is to redefine the prototype when you use it, i.e. after
all pgsql includes you define
extern DLLIMPORT int default_statistics_target;
in your sources. Apparently, the compiler will respect the latest
definition and resolve the reference cleanly.

Regards,
Andreas

Yep, DLLIMPORT is the right fix. Patch attached and applied.

---------------------------------------------------------------------------

Mark Cave-Ayland wrote:

Hi everyone,

I've been experimenting with compiling PostGIS (a contrib module) under
Win32 and I've noticed a difference in accessing GUC variables between
Linux and Win32 using PostgreSQL 8.0 beta 1. In part of the PostGIS
statistics routines we have a check like this:

#include "commands/vacuum.h"
...

/* If the attstattarget column is negative, use the default
value */
/* NB: it is okay to scribble on stats->attr since it's a copy
*/
if (attr->attstattarget < 0)
attr->attstattarget = default_statistics_target;

Under Linux, PostGIS compiles and links fine without any trouble.
However, when compiling under Win32 we get the following message:

Info: resolving _default_statistics_target by linking to
__imp__default_statistics_target (auto-import)
fu000024.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname'
nmth000023.o(.idata$4+0x0): undefined reference to
`_nm__default_statistics_target'
c:\mingw\bin\dllwrap.exe: c:\mingw\bin\gcc exited with status 1

The current "fix" to enable this to work correctly is to change the
relevant line in /src/include/commands/vacuum.h from "extern int
default_statistics_target;" to "extern DLLIMPORT int
default_statistics_target;". However, I'm not convinced this is the
correct fix given that other contrib modules may require access to other
GUC variables.

I've looked at guc.c and found GetConfigOption() which I think may be a
better option since I don't think accessing the variable directly will
work when using custom variables. Would this be the "correct" way to
access GUC variable values from within other modules that would work
correctly under both Win32 and UNIX-type OSs?

Cheers,

Mark.

---

Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England

Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446

This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: 17 August 2004 03:51
To: Mark Cave-Ayland
Cc: pgsql-hackers-win32@postgresql.org; PostgreSQL-patches
Subject: Re: [PATCHES] [pgsql-hackers-win32] GUC variables
invisible to contrib/ modules

Yep, DLLIMPORT is the right fix. Patch attached and applied.

--------------------------------------------------------------

Hi Bruce,

I had actually gone for Andreas' suggestion and included the DLLIMPORT
in an extern declaration so thanks for applying the patch. However, I'm
still not convinced that this is the best thing to do in this case. This
is because we either allow access to all GUC variables (in which case we
need to locate them all and mark them as DLLIMPORT) or otherwise provide
another mechanism to get this information.

Looking at Thomas' patch
(http://archives.postgresql.org/pgsql-patches/2004-04/msg00280.php) it
seems that using GetConfigOption() is the only way that will work
without knowing the underlying variable name that stores your GUC value
(this may not necessarily be the same name as the parameter in
postgresql.conf) and also work with new custom GUC variables. So I
guess I was looking more for clarification that this was the "official"
way to access GUC information? (I see this also as being less likely to
break in future, since if the underlying variable name changes,
everything will still work unless the parameter changes its name)

Many thanks,

Mark.

---

Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England

Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446

This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.

I am not really sure what the official way of accessing guc variables is
because we haven't had a lot of external apps using them in the past,
and Win32 is a newer platform for us.

---------------------------------------------------------------------------

Mark Cave-Ayland wrote:

-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: 17 August 2004 03:51
To: Mark Cave-Ayland
Cc: pgsql-hackers-win32@postgresql.org; PostgreSQL-patches
Subject: Re: [PATCHES] [pgsql-hackers-win32] GUC variables
invisible to contrib/ modules

Yep, DLLIMPORT is the right fix. Patch attached and applied.

--------------------------------------------------------------

Hi Bruce,

I had actually gone for Andreas' suggestion and included the DLLIMPORT
in an extern declaration so thanks for applying the patch. However, I'm
still not convinced that this is the best thing to do in this case. This
is because we either allow access to all GUC variables (in which case we
need to locate them all and mark them as DLLIMPORT) or otherwise provide
another mechanism to get this information.

Looking at Thomas' patch
(http://archives.postgresql.org/pgsql-patches/2004-04/msg00280.php) it
seems that using GetConfigOption() is the only way that will work
without knowing the underlying variable name that stores your GUC value
(this may not necessarily be the same name as the parameter in
postgresql.conf) and also work with new custom GUC variables. So I
guess I was looking more for clarification that this was the "official"
way to access GUC information? (I see this also as being less likely to
break in future, since if the underlying variable name changes,
everything will still work unless the parameter changes its name)

Many thanks,

Mark.

---

Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England

Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446

This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

"Mark Cave-Ayland" <m.cave-ayland@webbased.co.uk> writes:

So I guess I was looking more for clarification that this was the
"official" way to access GUC information?

It isn't, and isn't likely to become so, at least not for C code.
We generally think of the C code as being at a lower level than SQL.
If we rename a global variable that underlies a GUC variable, it's
probably because we *want* to break any C code that references it
--- perhaps the semantics are changing, or something like that.

regards, tom lane