Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Really? [ pokes around ... ] Hm, you're right, because
add_placeholder_variable() sets the GUC_NO_SHOW_ALL flag, and in this
usage it'll never be cleared. I wonder if we should change that.
The whole thing is a bit of an abuse of what the mechanism was
intended for, and so I'm not sure we should rejigger GUC's behavior
to make it more pleasant, but on the other hand if we're not ready to
provide a better substitute ...
While I agree with that part, is there any actual *reason* why we
shouldn't have the custom variables included in pg_settings?
I've needed it myself before -- I think it is a good idea.
IIRC, the motivation for doing that was to not expose a completely bogus
set of attributes for a variable whose defining C-module hadn't been
loaded yet.
I thought about this in the shower just now, and ISTM that if we want to
turn this into an actual feature rather than a kluge, there needs to be
some sort of "define variable" command that sets up a custom variable
and specifies its type (and whatever other properties seem worth
setting). IOW expose the DefineCustomFooVariable functions to SQL users.
I'd be a bit inclined to restrict the namespace that can be set up that
way, eg allow only "local." or "session." as the prefix. Maybe
that's just being too anal, but we could guarantee not to introduce
colliding built-in GUCs in future releases, whereas people trying to
define variables with any random name would definitely be at risk.
Comments?
Would it make sense to have built-in GUCs belong to "pg_catalog." and
user defined GUCs default to "public."?
Joe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
