Re: [PATCHES] GUC variables invisible to contrib/

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>
Cc: pgsql-hackers-win32(at)postgresql(dot)org, "'PostgreSQL-patches'" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [PATCHES] GUC variables invisible to contrib/
Date: 2004-08-17 15:15:36
Message-ID: 200408171515.i7HFFa401935@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32 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(at)postgresql(dot)org
> > [mailto:pgsql-patches-owner(at)postgresql(dot)org] On Behalf Of Bruce Momjian
> > Sent: 17 August 2004 03:51
> > To: Mark Cave-Ayland
> > Cc: pgsql-hackers-win32(at)postgresql(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Bruce Momjian 2004-08-17 15:16:52 Re: tablespace and sequences?
Previous Message Fabien COELHO 2004-08-17 15:09:34 Re: tablespace and sequences?

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-08-17 15:18:29 Re: [PATCHES] GUC variables invisible to contrib/ modules
Previous Message Bruce Momjian 2004-08-17 14:46:28 Re: libpq build problem with <io.h> on MS VC++