From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Ronan Dunklau <ronan(dot)dunklau(at)dalibo(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, david(at)fetter(dot)org |
Subject: | Re: IMPORT FOREIGN SCHEMA statement |
Date: | 2014-05-27 14:00:31 |
Message-ID: | 20140527140031.GJ2556@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Ronan Dunklau (ronan(dot)dunklau(at)dalibo(dot)com) wrote:
> So, without extending the syntax too much, we could add options:
>
> IMPORT FOREIGN SCHEMA remote_schema FROM SERVER server_name INTO local_schema
> [ { LIMIT TO | EXCEPT } (table_name [, ...])]
> [ OPTIONS (option_list) ]
>
> This option list could then contain fdw-specific options, including type
> mapping.
Yup, that looks reasonable to me.
> Or we could add a specific clause:
>
> IMPORT FOREIGN SCHEMA remote_schema FROM SERVER server_name INTO local_schema
> [ { LIMIT TO | EXCEPT } (table_name [, ...])]
> [ OPTIONS (option_list) ]
> [ TYPE MAPPING some mapping_definition ]
-1 on this one.
> With mapping_definition being either a tuple, or well-defined jsonb format
> common accross FDWs.
>
> A third solution, which I don't like but doesn't modify the SQL grammar, would
> be to encode the options in the remote_schema name.
Yeah, don't like that one either.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2014-05-27 14:04:39 | Re: IMPORT FOREIGN SCHEMA statement |
Previous Message | Stephen Frost | 2014-05-27 13:59:03 | Re: IMPORT FOREIGN SCHEMA statement |