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.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.
Kind regards,
Thomas Hallgren
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
