Re: [pgsql-hackers-win32] GUC variables invisible to contrib/ - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: [pgsql-hackers-win32] GUC variables invisible to contrib/
Date
Msg-id 200408171515.i7HFFa401935@candle.pha.pa.us
Whole thread Raw
In response to Re: [pgsql-hackers-win32] GUC variables invisible to contrib/ modules  ("Mark Cave-Ayland" <m.cave-ayland@webbased.co.uk>)
List pgsql-patches
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

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [pgsql-hackers-win32] libpq build problem with on MS VC++
Next
From: Tom Lane
Date:
Subject: Re: [pgsql-hackers-win32] GUC variables invisible to contrib/ modules