Re: Hiding a GUC from SQL

From: Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Hiding a GUC from SQL
Date: 2020-06-18 16:40:20
Message-ID: CACxu=v+McxG6Zj5HMGUGAKJmhXrAjc1BxGUz5C199+U=be5epw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Jun 17, 2020 at 3:55 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com> writes:
> > In my extension pgsodium I'm defining a custom variable at startup to
> store
> > a key:
>
> > https://github.com/michelp/pgsodium/blob/master/src/pgsodium.c#L1107
>
> > I'm using the flags GUC_NO_SHOW_ALL | GUC_NO_RESET_ALL |
> GUC_NOT_IN_SAMPLE
> > | GUC_DISALLOW_IN_FILE, and a custom "no show" show hook that obscures
> the
> > value. This idea was inspired from the pgcryptokey module from Bruce
> > Momjian.
>
> I guess I'm wondering why you're making it a GUC at all, if you don't
> want any of the GUC facilities to apply.
>

An excellent point as it's loaded pre-fork I guess I don't need any of that
stuff.

> It seems like if you want to be this paranoid, you'd be better off
> not exposing the variable to the GUC machinery in the first place.
> You could use a custom set-function (like setseed) to replace the one
> bit of functionality you do want.
>

Thanks! I've implemented your suggestion similar to how setseed stores its
data.

>
> regards, tom lane
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Paul Förster 2020-06-18 16:49:32 Re: Netapp SnapCenter
Previous Message Pepe TD Vo 2020-06-18 16:40:00 Re: create batch script to import into postgres tables