Re: inherit support for foreign tables
От | Tom Lane |
---|---|
Тема | Re: inherit support for foreign tables |
Дата | |
Msg-id | 15961.1430009224@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: inherit support for foreign tables (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: inherit support for foreign tables
|
Список | pgsql-hackers |
Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes: > On 2015/04/16 16:05, Etsuro Fujita wrote: >> I agree with you on this point. However, ISTM there is a bug in >> handling OIDs on foreign tables; while we now allow for ALTER SET >> WITH/WITHOUT OIDS, we still don't allow the default_with_oids parameter >> for foreign tables. I think that since CREATE FOREIGN TABLE should be >> consistent with ALTER FOREIGN TABLE, we should also allow the parameter >> for foreign tables. Attached is a patch for that. > I also updated docs. Attached is an updated version of the patch. I believe that we intentionally did not do this, and here is why not: existing pg_dump files assume that default_with_oids doesn't affect any relation type except plain tables. pg_backup_archiver.c only bothers to change the GUC when about to dump a plain table, and otherwise leaves it at its previous value. That means if we apply a patch like this, it's entirely possible that pg_dump/pg_restore will result in foreign tables accidentally acquiring OID columns. Since default_with_oids is really only meant as a backwards-compatibility hack, I don't personally have a problem with restricting it to act only on plain tables. However, it might be a good idea to explicitly document this interaction in a code comment to prevent anyone from re-inventing this idea... I'll go do that. regards, tom lane
В списке pgsql-hackers по дате отправления: