On Wed, Dec 03, 2014 at 06:17:51PM -0500, Tom Lane wrote:
> David Fetter <david@fetter.org> writes:
> > On Wed, Dec 03, 2014 at 05:52:03PM -0500, Tom Lane wrote:
> >> What do you mean "reconstruct the enum"?
>
> > Capture its state at the time when IMPORT FOREIGN SCHEMA is executed.
> > Right now, if you try IMPORT SCHEMA on a foreign table with an enum in
> > it, postgresql_fdw errors out rather than trying to notice that
> > there's an enum definition which should precede creation and execute
> > it in the correct order.
>
> Oh, you think IMPORT FOREIGN SCHEMA should try to import enums?
Yes.
> I doubt it. What happens if the enum already exists locally?
Informative error message along the lines of, "local enum foo.bar
doesn't match remote enum public.bar" with a suitable HINT comparing
the enums' values.
However, I don't see much of a use case for this because INTO SCHEMA
should be specifying an empty schema, or at least one without objects
in it (like ENUMs) that could clash.
> And why enums, and not domains, ranges, composite types, etc?
You'd be assuming I think those should be excluded. ;)
> Perhaps more to the point, IMPORT FOREIGN SCHEMA is defined in the
> SQL standard, as are its effects, and those effects are defined as a
> series of CREATE FOREIGN TABLE commands. There's nothing there
> about trying to import types that the tables might depend on.
The SQL standard has an awful lot of holes, this one being about the
size of the Chicxulub crater.
That fact doesn't force our implementation to throw up its hands when
it finds a feature we've implemented and encouraged people to use.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate