Re: pg_dump versus defaults on foreign tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump versus defaults on foreign tables
Date
Msg-id 23465.1368657875@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump versus defaults on foreign tables  (Josh Berkus <josh@agliodbs.com>)
List 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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Better handling of archive_command problems
Next
From: Josh Berkus
Date:
Subject: Re: "on existing update" construct