From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [RFC] Removing "magic" oids
Date: Sun, 14 Oct 2018 15:43:39 -0700
Message-ID: <20181014224339.i6pqo7kpgj7x5vq2@alap3.anarazel.de> (raw)
In-Reply-To: <943.1539556490@sss.pgh.pa.us>
References: <20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de>
<20181014220923.j4mlgue7y7chv533@alap3.anarazel.de>
<943.1539556490@sss.pgh.pa.us>
Hi,
On 2018-10-14 18:34:50 -0400, Tom Lane wrote:
> 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.
Yea, I agree that it'll cause some pain. And we could easily 'de-magic'
oids everywhere except the SELECT * processing (that'd probably leave
some behavioural difference with composite types, but there'd it'd
probably be purely be better).
I'm not sure we want that however - yes, the short time pain will be
lower, but do we really want to inflict the confusion about invisible
oids on our users for the next 20 years? I think there's a fair argument
to be made that we should cause pain once, rather continuing to inflict
lower doeses of pain.
> 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.
Right. And we could just use that for system columns too, removing a
number of special case logic. Seems not unlikely that we'll have further
magic columns that want to be hidden by default, given Kevin is
pondering re-starting his work on incremental matviews.
> 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.)
Right. I suspect that we at some point want to support having catalog
tables in different storage formats, but certainly not initially. Part
of the reason why I want to remove WITH OIDs support is precisely that I
do not want to add this kind of magic to other storage formats.
> 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.
Yea, I'm on-board with that.
Greetings,
Andres Freund
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: andres@anarazel.de, tgl@sss.pgh.pa.us
Subject: Re: [RFC] Removing "magic" oids
In-Reply-To: <20181014224339.i6pqo7kpgj7x5vq2@alap3.anarazel.de>
* 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