Re: [RFC] Removing "magic" oids

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [RFC] Removing "magic" oids
Дата
Msg-id 943.1539556490@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [RFC] Removing "magic" oids  (Andres Freund <andres@anarazel.de>)
Ответы Re: [RFC] Removing "magic" oids
Re: [RFC] Removing "magic" oids
Re: [RFC] Removing "magic" oids
Список pgsql-hackers
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.

BTW, the fact that we have magic OIDs in the system catalogs doesn't
mean that any other storage system has to support that.  (When I was
at Salesforce, we endured *substantial* pain from insisting that we
move the catalogs into their custom storage system.  There were good
reasons to do so, but it's not a decision I'd make again if there were
any plausible way not to.)

Personally, I'd drop WITH OIDs support for user tables altogether, rather
than having pg_dump create a "compatible" translation that won't be very
compatible if it loses the magicness aspect.

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: "SELECT ... FROM DUAL" is not quite as silly as it appears
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pgsql: Add TAP tests for pg_verify_checksums