Re: Proposal: IMPORT FOREIGN SCHEMA statement.

> Who says that the OIDs are the same on the local and the remove postgres
> instance? For user-defined types, that's certainly not going to be true...

That's why the the result is casted as regtype[], and parsed as such. The oid
is not transmitted over the wire, but set by regtype_in.

>
> Also, why do you aggregate the lists of columns, types and oids into arrays
> when querying them from the remote server? Just producing a query that
> returns one row per table column seems much simpler, both conceptually and
> implementation wise.

As I said, this is a Proof-Of-Concept. It is not meant to be a fully
functional, optimal implementation, but to serve as basis for discussion of
the API and the feature themselves.

The query could indeed be replaced by what you suggest, performing the
grouping locally. I have absolutely no opinion on which implementation is
better, this one seemed the most "natural" to me.

>
> Finally, I think there are a few missing pieces. For example, you quite
> easily could copy over not-NULL flags, but you currently don't. Similarly,
> what about inheritance relationships between remote tables? There's a patch
> in the current CF, I believe, which adds support for inheritance to foreign
> tables, so all you'd have to do is to make the foreign table's inheritance
> structure match the remote table's.

Duly noted, we could probably import NOT NULL flags, and maybe even the
table's inheritance structure. I'll look into that if the feature and the API
are deemed worthy.

Thank you for the review.

--
Ronan Dunklau
http://dalibo.com - http://dalibo.org