Re: [RFC] Removing "magic" oids
От | Andres Freund |
---|---|
Тема | Re: [RFC] Removing "magic" oids |
Дата | |
Msg-id | 20181014224339.i6pqo7kpgj7x5vq2@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [RFC] Removing "magic" oids (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [RFC] Removing "magic" oids
(Robert Haas <robertmhaas@gmail.com>)
|
Список | pgsql-hackers |
Hi, On 2018-10-14 18:34:50 -0400, Tom Lane 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. Yea, I agree that it'll cause some pain. And we could easily 'de-magic' oids everywhere except the SELECT * processing (that'd probably leave some behavioural difference with composite types, but there'd it'd probably be purely be better). 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. > 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. Right. And we could just use that for system columns too, removing a number of special case logic. Seems not unlikely that we'll have further magic columns that want to be hidden by default, given Kevin is pondering re-starting his work on incremental matviews. > 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.) Right. I suspect that we at some point want to support having catalog tables in different storage formats, but certainly not initially. Part of the reason why I want to remove WITH OIDs support is precisely that I do not want to add this kind of magic to other storage formats. > 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. Yea, I'm on-board with that. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: