Re: [RFC] Removing "magic" oids - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [RFC] Removing "magic" oids
Date
Msg-id 943.1539556490@sss.pgh.pa.us
Whole thread Raw
In response to Re: [RFC] Removing "magic" oids  (Andres Freund <andres@anarazel.de>)
Responses Re: [RFC] Removing "magic" oids  (Andres Freund <andres@anarazel.de>)
Re: [RFC] Removing "magic" oids  (Thomas Munro <thomas.munro@enterprisedb.com>)
Re: [RFC] Removing "magic" oids  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> Does anybody have engineering / architecture level comments about this
> proposal?

FWIW, I'm -1 on making OIDs be not-magic for SELECT purposes.  Yeah, it's
a wart we wouldn't have if we designed the system today, but the wart is
thirty years old.  I think changing that will break so many catalog
queries that we'll have the villagers on the doorstep.  Most of the other
things you're suggesting here could be done easily without making that
change.

Possibly we could make them not-magic from the storage standpoint (ie
they're regular columns) but have a pg_attribute flag that says not
to include them in "SELECT *" expansion.

BTW, the fact that we have magic OIDs in the system catalogs doesn't
mean that any other storage system has to support that.  (When I was
at Salesforce, we endured *substantial* pain from insisting that we
move the catalogs into their custom storage system.  There were good
reasons to do so, but it's not a decision I'd make again if there were
any plausible way not to.)

Personally, I'd drop WITH OIDs support for user tables altogether, rather
than having pg_dump create a "compatible" translation that won't be very
compatible if it loses the magicness aspect.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: "SELECT ... FROM DUAL" is not quite as silly as it appears
Next
From: Michael Paquier
Date:
Subject: Re: pgsql: Add TAP tests for pg_verify_checksums