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

From Robert Haas
Subject Re: [RFC] Removing "magic" oids
Date
Msg-id CA+TgmobCqGhnac0Brwkh-AUqhRMVba73fahLQPe+Z6nEJZoAwQ@mail.gmail.com
Whole thread Raw
In response to Re: [RFC] Removing "magic" oids  (Andres Freund <andres@anarazel.de>)
Responses Re: [RFC] Removing "magic" oids  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Sun, Oct 14, 2018 at 6:43 PM Andres Freund <andres@anarazel.de> wrote:
> 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.

Yeah, I think that argument has quite a bit of merit.  I suspect that
there are a lot of people who expect that 'SELECT * FROM pg_whatever'
is going to show them all of the data in pg_whatever, and take a while
to figure out that it really doesn't.  I know better and still mess
this up with some regularity.  Anyone who finds it unintuitive that *
doesn't really mean everything is going to be happier with this change
in the long run.

In the short run, it is indeed possible that some catalog queries will
break.  But, really, how many?  For the most part, automated queries
written by tools probably select specific columns rather than
everything, and IIUC those won't break.  And even if they do use
'SELECT *', won't they just end up with two copies of the OID column?
That might work fine.

Of course it might not, and then you'd have to fix your code, but it's
not obvious to me that this would be a horror show.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PG vs macOS Mojave
Next
From: Tom Lane
Date:
Subject: Re: pg_dump multi VALUES INSERT