On Sun, Oct 14, 2018 at 6:35 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@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. > > 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.
I think such a flag would be a good idea; it seems to have other uses. As Andres also noted, Kevin was quite interested in having a hidden-by-default COUNT column to assist with materialized view maintenance, and presumably this could also be used for that purpose. I am less sure that it's a good idea that it's a good idea to set that flag for the OID columns in system catalogs. I do think that some tool authors are likely to have to do some significant work to update their tools, but a lot of tools are probably already querying for specific columns, not using *, so they'll be fine. And like Andres says, it seems like we'll be happier in the long term if we get way from having OID columns be invisible in system catalogs. That's just confusing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
