Le mardi 27 mai 2014 09:52:27 Stephen Frost a écrit :
> * David Fetter (david@fetter.org) wrote:
> > In the "easy" case of PostgreSQL, you might also be able to establish
> > whether the UDT in the "already defined locally" case above is
> > identical to the one defined remotely, but I don't think it's possible
> > even in principle for non-PostgreSQL remote systems, possibly not even
> > for ones with non-identical architecture, PostgreSQL major version,
> > etc.
>
> For my 2c, it'd be very handy if IMPORT had an option or similar to also
> copy over all (in the schema) or at least any depended-upon UDTs. It'd
> really be nice if we had an ability to check the remote UDT vs. the
> local one at some point also, since otherwise you're going to get bitten
> at run-time when querying the foreign table.
The specification only talks about importing tables, not types, views or (why
not ?) foreign tables.
If we want to extend the spec further, we could accept more than
CreateForeignTableStmt as return values from the API:- CreateDomainStmt- CompositeTypeStmt- AlterTableCmd
The core code would be responsible for executing them, and making sure the
destination schema is correctly positioned on all of those.
The postgres_fdw behaviour could then be controlled with options such as
include_types (tri-valued enum accepting "none", "all", "as_needed"),
relation_kinds (default to 'r', can support multiple kinds with a string 'rfv'
for tables, foreign tables and views).
I think we're drifting further away from the standard with that kind of stuff,
but I'd be happy to implement it if that's the path we choose.
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
