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
>
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 |