How about sending an INFO or special taged message to the client when
there is a GUC change, and have report_changes as a GUC variable that
controls it?
---------------------------------------------------------------------------
Tom Lane wrote:
> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
