On Sun, Oct 14, 2018 at 6:35 PM Tom Lane <tgl@sss.pgh.pa.us> 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.
>
> 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
