Re: pg_dump versus defaults on foreign tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump versus defaults on foreign tables
Дата
Msg-id 23465.1368657875@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump versus defaults on foreign tables  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
>> Comments?

> I personally think that FOREIGN should be optional on most commands
> where ambiguity is unlikely.  In addition to ALTER, there's no
> particularly good reason why "DROP TABLE myforeigntable" doesn't work.

Well, it's certainly bizarre that we allow ALTER TABLE to work for most
non-table relation types (eg views, sequences) but specifically exclude
foreign tables, which after all are *called* tables.  So I think that's
just plain wrong.

I'm less excited about changing the DROP case, because there is
precedent extending way back for being anal about that case, eg
we do this at least as far back as 7.4:

regression=# create sequence s1;
CREATE SEQUENCE
regression=# drop table s1;
ERROR:  "s1" is not a table
HINT:  Use DROP SEQUENCE to remove a sequence.

I'm not against being laxer about DROP, but it ought to be a
thought-through change that considers what to do for all relation types
not just foreign tables.  In particular, should it follow the precedent
of ALTER TABLE that we allow "ALTER TABLE" on non-tables but if you use
another spelling such as "ALTER SEQUENCE" then it has to match the
relation type?

In any case, that restriction isn't breaking pg_dump so I don't feel
a need to change it during beta.
        regards, tom lane



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Better handling of archive_command problems
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: "on existing update" construct