On 12/18/2016 02:47 PM, Corey Huinker wrote:
> On Sun, Dec 18, 2016 at 4:57 PM, Michael Paquier wrote:
>> On Mon, Dec 19, 2016 at 6:48 AM, Joe Conway wrote:
>>> Maybe if "CREATE FOREIGN DATA WRAPPER" had a way to specify that the FDW
>>> supports a libpq connection it would make sense to allows
On Sun, Dec 18, 2016 at 4:57 PM, Michael Paquier
wrote:
> On Mon, Dec 19, 2016 at 6:48 AM, Joe Conway wrote:
> > Maybe if "CREATE FOREIGN DATA WRAPPER" had a way to specify that the FDW
> > supports a libpq connection it would make sense to allows
On Mon, Dec 19, 2016 at 6:48 AM, Joe Conway wrote:
> Maybe if "CREATE FOREIGN DATA WRAPPER" had a way to specify that the FDW
> supports a libpq connection it would make sense to allows other FDWs
> with this attribute, but since there is none the current state strikes
> me as
On 11/21/2016 03:59 PM, Corey Huinker wrote:
> On 11/21/2016 02:16 PM, Tom Lane wrote:
>> The dblink docs recommend using dblink_fdw as the FDW for this purpose,
>> which would only accept legal connstr options. However, I can see the
>> point of using a postgres_fdw server instead, and
On Tue, Nov 22, 2016 at 3:29 PM, Tom Lane wrote:
> Corey Huinker writes:
> > In 9.4, I encountered a complaint about flex 2.6.0. After a little
> research
> > it seems that a fix for that made it into versions 9.3+, but not 9.4.
>
> Er ... what? See
Corey Huinker writes:
> In 9.4, I encountered a complaint about flex 2.6.0. After a little research
> it seems that a fix for that made it into versions 9.3+, but not 9.4.
Er ... what? See 1ba874505.
regards, tom lane
--
Sent via
>
>
>
>> It looks like this might be fairly easy to fix by having
>> get_connect_string() use is_valid_dblink_option() to check each
>> option name, and silently ignore options that are inappropriate.
>>
>
> From what I can tell, it is very straightforward, the context oids are set
> up just a few
>
> The dblink docs recommend using dblink_fdw as the FDW for this purpose,
> which would only accept legal connstr options. However, I can see the
> point of using a postgres_fdw server instead, and considering that
> dblink isn't actually enforcing use of any particular FDW type, it seems
>
On 11/21/2016 02:16 PM, Tom Lane wrote:
> Corey Huinker writes:
>> I ran into this today:
>> CREATE SERVER bob_srv FOREIGN DATA WRAPPER postgres_fdw OPTIONS ( host
>> 'localhost', dbname :'current_db' );
>> ...
>> ALTER SERVER bob_srv OPTIONS (updatable 'true');
>> SELECT
Corey Huinker writes:
> I ran into this today:
> CREATE SERVER bob_srv FOREIGN DATA WRAPPER postgres_fdw OPTIONS ( host
> 'localhost', dbname :'current_db' );
> ...
> ALTER SERVER bob_srv OPTIONS (updatable 'true');
> SELECT *
> FROM dblink('bob_srv','SELECT 1') as t(x
On Sun, Nov 20, 2016 at 7:37 PM, Corey Huinker wrote:
> I ran into this today:
>
> select current_database() as current_db \gset
> CREATE EXTENSION postgres_fdw;
> CREATE EXTENSION
> CREATE EXTENSION dblink;
> CREATE EXTENSION
> CREATE ROLE bob LOGIN PASSWORD 'bob';
>
11 matches
Mail list logo