Re: Move postgresql_fdw_validator into dblink - Mailing list pgsql-hackers

Hanada-san,

What about your plan to upstream contrib/pgsql_fdw module on the upcoming
commit-fest?
Even though I understand the point I noticed (miss-synchronization of sub-
transaction block between local and remote side) is never easy problem to
solve, it is worth to get the patch on the table of discussion.
In my opinion, it is an idea to split-off the transaction control portion as
a limitation of current version. For example, just raise an error when
the foreign-table being referenced in sub-transaction block; with explicit
description in the document.

Anyway, let me pick up your patch for reviewing. And, I hope you to prepare
contrib/pgsql_fdw patch based on this patch.

2012/9/11 Shigeru HANADA <shigeru.hanada@gmail.com>:
> I'd like to propose moving postgresql_fdw_validator into contrib/dblink
> as dblink's own validator.
>
> Main purpose of this proposal is to reserve the name "postgresql_fdw"
> for concrete FDW for PostgreSQL.  I used to use "pgsql_fdw" as the name,
> but in previous CF I got comments that full product name is appropriate
> rather than abbreviation (e.g. pgsql_fdw) for FDW's name.
>
> In addition, this change would avoid potential problem that third-party
> product might use this validator and introduce undesirable dependency
> between PG core.
>
> This change breaks backward compatibility, but AFAIK no one except
> dblink seems to use this validator, so it would not be serious problem.
> # Please let me know if any product uses this validator!
>
> Changes in this patch are:
>
> 1) Move postgresql_fdw_validator from core backend to contrib/dblink
> with renaming to dblink_fdw_validator.  Also I modified this validator
> so that it uses PQconndefault() to get libpq's valid options instead of
> having its own options list.
>
> 2) For ease of use, dblink's CREATE EXTENSION provides default FDW
> dblink_fdw which accepts libpq's connection options via user mapping
> ("user" and secret options such as "password") and foreign server (all
> other options).
>
> 3) Bump dblink's version to 1.1.  Of cource upgrade script is provided.
>
> 4) Update documents. (Should we mention removal of
> postgresql_fdw_validator?)
>
> 5) Use simplified postgresql_fdw_validator in regression test
> foreign_data.  I didn't change actual test cases because they don't seem
> to depend on postgresql_fdw_validator deeply.
>
> Comments and questions are welcome.
> --
> Shigeru HANADA
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>



-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>