Re: pg_dump versus defaults on foreign tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump versus defaults on foreign tables
Date: 2013-05-15 22:44:35
Message-ID: 23465.1368657875@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-05-15 22:53:24 Re: "on existing update" construct
Previous Message Peter Geoghegan 2013-05-15 22:40:06 Re: Better handling of archive_command problems