Concerns about this release

I know I have expressed these concerns before but lost the argument, or
at least no one rallied to my position, but I feel I have to mention
these again because they came up during beta.

My first concern is that VACUUM now defaults to the non-locking version.
While I appreciate the new non-locking code, I imagine a release where
non-locking VACUUM will happen automatically, making no need to run
VACUUM.  However, locking VACUUM will still need to be run by
administrators, so we may be left with a VACUUM no one needs to run but
a VACUUM FULL that does need to be run, leaving us with a useless
default for VACUUM without the FULL keyword.  Also, because VACUUM does
not store the freetuple list between postmaster restarts, nor does it
have any way of recording _all_ free tuples, it has to be run with a
different frequency than the old VACUUM that I assume most people ran at
night.  I would have preferred to leave VACUUM as locking VACUUM and
create a new lighter option to the VACUUM command, and if light vacuum
later becomes automatic, the option can just go away.

Second, I am concerned about the removal of oids from system tables.  I
realize this was done to prevent oid usage, particularly by the creation
of temp tables, but such savings only make sense when oids are turned
off in postgresql.conf.  I imagine future releases where we have a
separate oid counter for system/user tables, or 8-bytes oids, in which
case the removal of oids from system tables may be needless.  We have
seen OpenACS is broken now because the new pg_description requires a
separate classoid/objsubid columns to uniquely access tables without
oids, like pg_attribute.  These new columns are used only for non-oid
tables, making access cumbersome, rather than the simpler oid lookup.  I
don't even know if the current setup will allow other tables without
oids to be referenced cleanly.  Object dependency tracking, using
pg_depend, will also require these additional fields to track
dependency, rather than just using the oid, and such access will be more
confusing.

I realize the motivation for these changes were to make PostgreSQL more
enterprise-ready, but I am concerned these changes may need to be
modified in future releases, causing confusion and porting problems for
users.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026