Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Actually, looking at this email, having a SET that is unchangeable would
> fix the issues with autocommit, datestyle, and client encoding for jdbc.
> The basic issue is that certain interfaces want to set these parameters
> as unchangeable, and that would allow this.
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.
On the other hand, that only directly solves the problem for a single
layer of client library. Imagine, say, a middleware layer built on top
of JDBC. If that layer wants to track the state of DATESTYLE, or any
other parameter, do these mechanisms help it? No, unless JDBC exposes
the parameter-update-reporting protocol ... which it probably won't
because that's not part of the JDBC API spec.
When you look at the problem in terms of N levels of client-side code,
I fear that none of the ideas we've discussed really provide a
satisfactory answer. Reporting doesn't work unless the reports
propagate all the way up the client stack. "Unchangeable params" don't
work --- which level gets to dictate the actual setting, and how do the
other levels learn what it is?
Any thoughts about it?
regards, tom lane
