From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [RFC] Removing "magic" oids
Date: Sun, 14 Oct 2018 18:34:50 -0400
Message-ID: <943.1539556490@sss.pgh.pa.us> (raw)
In-Reply-To: <20181014220923.j4mlgue7y7chv533@alap3.anarazel.de>
References: <20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de>
<20181014220923.j4mlgue7y7chv533@alap3.anarazel.de>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de
Subject: Re: [RFC] Removing "magic" oids
In-Reply-To: <943.1539556490@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox