Peter Eisentraut <peter_e@gmx.net> writes:
> Is there a reason why the vacuum tracking columns in pg_stat_all_tables
> etc. were added before the existing columns? I find this to be a very
> inconvenient regression because I use the counter columns much more
> often. What is the rationale for that?
Convenience is in the eye of the beholder, but perhaps a less subjective
argument for putting them at the end is that it'll be less likely to
break applications that do "select * from pg_stat_all_tables".
Either way, though, these are mighty weak arguments for forcing initdb
at the very end of the beta cycle. Can we get away with changing the
views without bumping the catversion? I did something similar last week
for that information_schema bug:Although this patch changes the initial catalog contents, I didn'tforce initdb. Any
beta3testers who need the fix can install itvia CREATE OR REPLACE VIEW, so forcing them to initdb seems anunnecessary
imposition.
The stats views can likewise be fixed by dropping and recreating them,
but since it's a pretty obviously user-visible change this may not be
a suitable candidate for that approach.
regards, tom lane
