Skip site navigation (1) Skip section navigation (2)

Re: simply custom variables protection

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com>, pgsql-patches(at)postgresql(dot)org, andrew(at)dunslane(dot)net
Subject: Re: simply custom variables protection
Date: 2007-04-07 17:38:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Pavel Stehule wrote:
>> My patch allows to allert somebody so any custom variable is protected.

> How does a user protect a custom variable using your code?  I don't see
> any API that would allow that.

The call would have to come from the loadable library that defines the
custom variable.  However, the complaint I had was that we already have
an API that should be able to do this, namely setting a protection level
higher than PGC_USERSET in the DefineCustomVariable call.  That doesn't
work today, but the right answer is to make it work, not invent more
functions.  This was agreed to be the right approach some time ago,
see thread here:

Pavel's proposed patch complicates the API and the code, and offers only
part of the same functionality, ie, the equivalent of PGC_SUSET; but
I think that for example PGC_SIGHUP is a perfectly reasonable setting
to want to use with a custom variable.

Furthermore I believe the patch is incomplete/wrong, because it adds
only one check on the "armored" flag, whereas PGC_SUSET affects behavior
in a number of places.  I also notice that it will make setting of a
an armored custom variable from postgresql.conf fail outright in
non-superuser sessions, which is surely not desirable.

In short: this isn't a feature, it's a wart.

			regards, tom lane

In response to


pgsql-patches by date

Next:From: Pavel StehuleDate: 2007-04-07 17:42:37
Subject: Re: simply custom variables protection
Previous:From: Pavan DeolaseeDate: 2007-04-07 16:58:23
Subject: Re: [HACKERS] Optimized pgbench for 8.3

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group