Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> I'm not sure they need these parameters to be *unchangeable*. What they
> >> need is to *know what they are*, with certainty. The notion of issuing
> >> an automatic report message whenever the values change would seem to
> >> answer that.
>
> > What concerns me also about the reporting problem is that some of these
> > interfaces must issue queries in several places in the code, so somehow
> > they have to make sure they check for those _special_ values in all
> > those places.
>
> Not sure what your point is here. If an interface is going to support
> more than one value of a parameter, then yes it has to be sure to do the
> right thing in each affected place. There's no shortcut for that.
I realize the transaction status varies from query to query, so that can
be hard-wired into the protocol --- but the other ones seem mostly to be
cases where you don't want the user changing something behind the back
of the interface. If we give the interface more control, we don't have
to report back the SET status. The only case that doesn't work is for
psql client encoding, where psql wants to know the user changed it ---
in such cases a SET in psql would fail, and the user would be instructed
to use the interface-specific method for changing that variable.
-- 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