Re: [RFC] Removing "magic" oids

On Sun, Sep 30, 2018 at 9:18 AM Andres Freund <andres@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