Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I have another interesting idea. What if we create a postgresql.conf
> > param called prev_compatible that exists in every release. We default
> > it to false/0. If it always exists, we can add features under its
> > control even in minor releases. Most interesting would be to have it be
> > an int and make a bitmask for up to 32 features that could be made
> > backward compatible to the previous release.
>
> Including the definition of the individual bits' behavior?
>
> That strikes me as a mess. No one could ever be very sure what behavior
> they were getting or not getting by setting such a thing. But they
> could be quite sure that their code would break in interesting ways in
> the next release.
>
> If we're going to have compatibility flags, they should be clearly
> defined, clearly named, and control just one feature apiece (cf.
> transform_null_equals).
You would define the bits in the release notes. postgresql.conf only
gets created as part of initdb, and because minor releases don't initdb,
it would be easier to have a single variable that always exists.
--
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, Pennsylvania 19073