Tom Lane wrote:
> The sort of semantic funny I am thinking of is like this:
> * postgresql.conf contains pljava::var = somegoodvalue
> * ALTER DATABASE SET supplies pljava::var = somebadvalue
> For builtin variables the ALTER DATABASE value would be rejected on
> sight and the end result would be that the variable contains
> 'somegoodvalue'. However if we don't yet know the variable at backend
> startup, 'somebadvalue' will replace 'somegoodvalue' completely, and
> then when the PL actually gets loaded it will get thrown away. End
> result is that the variable will have whatever its hardwired default is,
> and not 'somegoodvalue' as one would wish. Even more surprising, a
> subsequent SIGHUP would make it acquire 'somegoodvalue'.
>
> This particular case could be dealt with by forcing a rescan of
> postgresql.conf after new variables are defined (I think we need only do
> so if any errors are detected in assigning values), but that will not
> handle everything. We don't have any way to get back overridden values
> from other sources such as the postmaster command line.
>
This is the one case that I, after some consideration, decided not to
deal with. I feel that a rescan will only partially solve the problem
anyway. There might have been multiple assignments to a placeholder
prior to when the module is loaded. The only way to implement something
in this direction is to remember all assignments that has been made to
each placeholder variable and then fall back to the last one that has an
OK value once the module loads. Since a warning mechanism is in place
already I felt that such an implementation would be overkill.
Kind regards,
Thomas Hallgren
