On Sun, Sep 30, 2018 at 9:18 AM Andres Freund <and...@anarazel.de> wrote: > > Hi, > > In my opinion the current WITH OIDs system has numerous weaknesses: > > 1) The fact that oids are so magic means that if we get pluggable > storage, the design of the potential pluggable systems is constrained > and similar magic has to be present everywhere. > > 2) The fact that the oids in each table have the same counter to be > based on means that oid wraparounds have much worse consequences > performance wise than necessary. E.g. once the global counter has > wrapped, all toast tables start to be significantly slower. > > It would be much better if most database objects had their own > counters. > > 3) For some oid using objects (toast, large objects at the very least) > it'd be quite worthwhile to switch to 8 byte ids. Currently that's > hard to do, because it'd break on-disk compatibility. > > 4) There's a lot of special case code around for dealing with oids. > > 5a) The fact that system table oids don't show up in selects by default > makes it more work than necessary to look at catalogs. > > 5b) Similarly, it's fairly annoying when debugging not to trivially see > oids for catalog structs. > > > I think we should drop WITH OIDs support. pg_dump should convert WITH > OIDs tables into tables that have an explicit oid column (with an > appropriate default function), pg_upgrade should refuse to upgrade them. >
Is there any technical reason why you think pg_upgrade should refuse to upgrade them? I think there is an argument to break backward compatibility here and many people on the thread seem to be okay with that, but refusing to upgrade sounds more restrictive. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
