Date: Sun, 14 Oct 2018 15:43:39 -0700
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
Message-ID: <20181014224339.i6pqo7kpgj7x5vq2@alap3.anarazel.de>
References: <20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de>
 <20181014220923.j4mlgue7y7chv533@alap3.anarazel.de>
 <943.1539556490@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <943.1539556490@sss.pgh.pa.us>
Precedence: bulk

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