From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | pg_dump versus defaults on foreign tables |
Date: | 2013-05-15 20:34:07 |
Message-ID: | 19884.1368650047@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
While fooling with the issue of serial columns for foreign tables,
I noticed that pg_dump will sometimes try to restore a default
expression with a command like this:
ALTER TABLE ONLY rem ALTER COLUMN f1 SET DEFAULT nextval('rem_f1_seq'::regclass);
which when applied to a foreign table gets you
ERROR: "rem" is a foreign table
HINT: Use ALTER FOREIGN TABLE instead.
Now, I suppose we could kluge up pg_dump to emit ALTER FOREIGN TABLE
instead, but I'd like to object to this degree of anal retentivity.
There is *no* good reason to refuse this command, and plenty of
precedent in favor of being laxer. Most ALTER TABLE variants have
historically allowed any relation type for which the action is sensible.
As an example, three lines earlier in this same dump file I find
ALTER TABLE public.rem_f1_seq OWNER TO postgres;
for which we are not bleating that you have to use ALTER SEQUENCE
instead (and we'd better not start, since this usage is well embedded
in existing dump files).
Comments?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2013-05-15 20:57:23 | Re: pg_dump versus defaults on foreign tables |
Previous Message | Claudio Freire | 2013-05-15 20:10:39 | Re: Parallel Sort |