Re: [RFC] Removing "magic" oids

On Wed, Oct 17, 2018 at 9:22 PM Stephen Frost <sfrost@snowman.net> wrote:
>
> Greetings,
>
> * Robert Haas (robertmhaas@gmail.com) wrote:
> > 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.
>
> I tend to agree that this won't be as much of a horror show as made out
> to be up-thread.

+1.

>  Tools should certainly be using explicit column names
> and if they aren't then we're breaking them regularly anyway whenever
> we change what columns exist in a given catalog table.
>

I think we can't say with any certainty that how many application will
break, but if I have to guess then some will surely break, however, I
think it will be a good decision for the long term.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com