On Wed, Dec 03, 2014 at 06:17:51PM -0500, Tom Lane wrote: > David Fetter <da...@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 <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
