> 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
signature.asc
Description: This is a digitally signed message part.
