Peter Eisentraut <peter_e@gmx.net> writes:
> And where does it stop? There are about a dozen GUC variables that will
> break an application as a whole if they don't have the value expected by
> the application. Do we need to install guards against all of these?
The issue in my mind is not what will break an application, but what
will break a client-side library. The application knows, in some sense,
what settings it has selected -- either because it did explicit SETs or
because it's coded expecting certain values to be supplied via the GUC
default mechanisms. And the server knows what values have been set,
too. But the client-side library is out of the loop. We need to bring
it into the loop, at least for the values it needs to know about (and
yes, I agree that that's not a very well-defined set, but we can easily
set up the protocol to allow an expansible set of variables to be
transmitted).
I think that "don't do that" is not an acceptably robust solution.
Building software that falls over because someone exercised a perfectly
legitimate feature of another part of the system just isn't my idea of
the way to build stuff. We've had to put up with some cases of that
because we didn't want to change the protocol to fix it --- but now is
our opportunity to fix it.
regards, tom lane