Thread: Re: [pgsql-hackers-win32] GUC variables invisible to contrib/ modules

Re: [pgsql-hackers-win32] GUC variables invisible to contrib/ modules

From
"Mark Cave-Ayland"
Date:
> -----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.



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

From
Bruce Momjian
Date:
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

Re: [pgsql-hackers-win32] GUC variables invisible to contrib/ modules

From
Tom Lane
Date:
"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