Re: [RFC] Removing "magic" oids

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [RFC] Removing "magic" oids
Дата
Msg-id CA+TgmobCqGhnac0Brwkh-AUqhRMVba73fahLQPe+Z6nEJZoAwQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [RFC] Removing "magic" oids  (Andres Freund <andres@anarazel.de>)
Ответы Re: [RFC] Removing "magic" oids
Список pgsql-hackers
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PG vs macOS Mojave
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump multi VALUES INSERT