Re: pgsql_fdw in contrib - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: pgsql_fdw in contrib
Date
Msg-id CADyhKSW-2GR1Rv+PZ+Jh5Pzpac6fa_-Y=tkkEBziMEm6EnAUhg@mail.gmail.com
Whole thread Raw
In response to Re: pgsql_fdw in contrib  (Shigeru HANADA <shigeru.hanada@gmail.com>)
Responses Re: pgsql_fdw in contrib  (Shigeru HANADA <shigeru.hanada@gmail.com>)
List pgsql-hackers
Hanada-san,

What about the status of your patch?

Even though the 1st commit-fest is getting closed soon,
I'd like to pay efforts for reviewing to pull up the status of
pgsql_fdw into "ready for committer" by beginning of the
upcoming commit-fest.

Thanks,

2012/7/13 Shigeru HANADA <shigeru.hanada@gmail.com>:
> (2012/07/12 20:48), Kohei KaiGai wrote:
>> It seems to me what postgresql_fdw_validator() is doing looks like
>> a function to be named as "libpq_fdw_validator()".
>>
>> How about your opinion? It will help this namespace conflicts.
>
> I'd prefer dblink_fdw_validator.
>
> The name "libpq_fdw_validator" impresses me that a concrete FDW named
> "libpq_fdw" is somewhere and it retrieves external data *from* libpq.
> Indeed postgresql_fdw_validator allows only some of libpq options at the
> moment, but we won't be able to rename it for backward compatibility
> even if it wants to have non-libpq options in the future.
>
> IMO basically each FDW validator should be owned by a particular FDW,
> because in most cases validator should know FDW's internal deeply.  In
> addition, it would want to have new options for new features.
>
> Besides naming, as mentioned upthread, removing hard-coded libpq options
> list from dblink and leaving it to libpq client library would make
> dblink more robust about libpq option changes in future.
>
> Regards,
> --
> Shigeru HANADA
>
>
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Using pg_upgrade on log-shipping standby servers
Next
From: Andres Freund
Date:
Subject: [PATCH] XLogReader v2