Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackers-win32pgsql-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

pgsql-patches by date

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

pgsql-hackers-win32 by date

Next:From: Bruce MomjianDate: 2004-08-17 15:16:52
Subject: Re: tablespace and sequences?
Previous:From: Fabien COELHODate: 2004-08-17 15:09:34
Subject: Re: tablespace and sequences?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group