From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Hiding a GUC from SQL |
Date: | 2020-06-17 22:55:25 |
Message-ID: | 1513794.1592434525@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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.
As far as I can think at the moment, putting in a no-op show hook
is sufficient to prevent the value from being seen at the SQL level.
However, it's far from clear that doing that isn't going to have
negative side-effects; it'll possibly also break other things like
GUC save/restore (eg rolling back when a transaction fails).
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | prachi surangalikar | 2020-06-18 02:14:26 | i am getting issue as FATAL: password authentication failed for user ' postgres' tried |
Previous Message | Michel Pelletier | 2020-06-17 20:23:19 | Hiding a GUC from SQL |