From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "Ronan Dunklau *EXTERN*" <ronan(dot)dunklau(at)dalibo(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: IMPORT FOREIGN SCHEMA statement |
Date: | 2014-05-26 10:33:12 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B17CFE029@ntex2010i.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ronan Dunklau wrote:
> Since my last proposal didn't get any strong rebuttal, please find attached a
> more complete version of the IMPORT FOREIGN SCHEMA statement.
>
> I tried to follow the SQL-MED specification as closely as possible.
>
> This adds discoverability to foreign servers. The structure of the statement
> as I understand it is simple enough:
>
> IMPORT FOREIGN SCHEMA remote_schema FROM SERVER some_server [ (LIMIT TO |
> EXCEPT) table_list ] INTO local_schema.
>
> The import_foreign_schema patch adds the infrastructure, and a new FDW
> routine:
>
> typedef List *(*ImportForeignSchema_function) (ForeignServer *server,
> ImportForeignSchemaStmt * parsetree);
>
> This routine must return a list of CreateForeignTableStmt mirroring whatever
> tables were found on the remote side, which will then be executed.
In addition to data type mapping questions (which David already raised)
I have one problem when I think of the Oracle FDW:
Oracle follows the SQL standard in folding table names to upper case.
So this would normally result in a lot of PostgreSQL foreign tables
with upper case names, which would be odd and unpleasant.
I cannot see a way out of that, but I thought I should mention it.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-05-26 12:50:42 | Re: Re: popen and pclose redefinitions causing many warning in Windows build |
Previous Message | Matteo Beccati | 2014-05-26 10:03:19 | Re: [PATCH] Replacement for OSSP-UUID for Linux and BSD |