Bruce Momjian escribió: > > I have no problem removing the parameter if required to. In that case, > > I would like to leave the parameter in until mid beta, to allow > > greater certainty.
Uhm. If we remove a GUC during beta we don't need to force an initdb. At worst we will need to keep a no-op GUC variable that is removed in the next devel cycle. That said, if we're going to have a GUC that's going to disappear later, I think it's better to wait for 2 releases as proposed, not remove mid-beta. > > In any case, I would wish to retain as a minimum an extern bool > > variable allowing it to be turned off by C function if desired. I think this amounts to having an undocumented GUC that is hard to change. I prefer the GUC, myself. > Anything changed to postgresql.conf during beta is going to require an > initdb. > Also, lots of backward-compatibility infrastructure, as you are > suggesting above, add complexity to the system. > > I am basically against a GUC on this. We have far larger problems with > 9.3 than backward compatibility, and limited resources. If we have a clear plan on removing the parameter, it's easy enough to follow through. I don't think lack of resources is a good argument, because at that point there will be little to discuss and it's an easy change to make. And I think the plan is clear: if no bug is found the parameter is removed. If a bug is found, it is fixed and the parameter is removed anyway. Honestly, I would prefer that we push a patch that has been thoroughly reviewed and in which we have more confidence, so that we can push without a GUC. This means mark in CF as needs-review, then some other developer reviews it and marks it as ready-for-committer. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
