On Wed, Dec 3, 2014 at 5:17 PM, Tom Lane <t...@sss.pgh.pa.us> 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? > I doubt it. What happens if the enum already exists locally? > And why enums, and not domains, ranges, composite types, etc?
Probably IMPORT FOREIGN SCHEMA should not attempt to include type dependencies. However, if they are present in the importer (that is, the type exists by name), it should assume that they are correct come what may. Something like 'IMPORT FOREIGN TYPE' would probably be needed to translate a type between servers. Unless the SQL standard has it or gets it I doubt it will ever appear but the status quo isn't too bad IMO. Personally I have no issues with the risks involved with type synchronizion; the problems faced are mostly academic with clean errors and easily managed unless binary format is used with postgres to postgres transfer (which IIRC the postgres fdw does not utilize at this time). User created types can't be transmitted between servers with the existing binary format; you have to transmit them as text and hope the structures agree. Binary format transmission in postgres tends to be quite a bit faster depending on the nature of the types involved, things like ints, numerics, and timestamps tend to be much faster. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
