On Wed, Oct 17, 2018 at 9:22 PM Stephen Frost <sfr...@snowman.net> wrote: > > Greetings, > > * Robert Haas (robertmh...@gmail.com) wrote: > > On Sun, Oct 14, 2018 at 6:43 PM Andres Freund <and...@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
