Re: Concerns about this release

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I know I have expressed these concerns before but lost the argument,
> 
> Yes, you did, and it's way too late to bring them up again.
> Particularly the OID issue; do you seriously propose an initdb
> at this stage to put back OIDs in the system tables?

No, I don't expect any changes.  I just felt I needed to clearly state
my opinion on this so people know where we are headed.

> But for the record:
> 
> I think your argument about VACUUM misses the point.  The reason FULL
> isn't the default is that we want the default form to be the one people
> most want to use.  If lightweight VACUUM starts to be run automatically
> in some future release, FULL might at that time become the default.
> I don't see anything wrong with changing the default behavior of the
> command whenever the system's other behavior changes enough to alter the
> "typical" usage of the command.

Agreed.  VACUUM nolock will be the most used method of vacuum for 7.2.

My concern was that FULL is still needed sometimes _and_ may become the
more popular vacuum method in later releases as vacuum nolock becomes
automatic.  

Vacuum may go from locking (7.1), to non-locking (7.2), to locking (7.3)
in the span of three releases.  My point was that keeping vacuum as
locking in all releases and adding a non-locking version only for 7.2
seemed cleaner.

Now, if you think we will continue needing a non-locking vacuum in all
future releases then we are doing the right thing by making non-locking
the default.  Is that true?

> As for pg_description, the change in primary key is unfortunate but
> *necessary*.  I don't foresee us reversing it.  The consensus view as
> I recall it was that we wanted to go over to a separate OID generator
> per table in some future release, which fits right in with the new
> structure of pg_description, but is entirely unworkable with the old.

In other words, a separate sequence for each system table, right?  Is
that where we are headed?  We could still call the column oid and
queries would continue to work.  I don't think there are many
cases where the oid is used to find a particular table, except my
/contrib/findoidjoins, which can be removed.

--  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