On Wed, Dec 3, 2014 at 5:17 PM, Tom Lane <tgl@sss.pgh.pa.us> 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?
> 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