Re: IMPORT FOREIGN SCHEMA statement

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

In response to

Browse pgsql-hackers by date

  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