Re: Move postgresql_fdw_validator into dblink

Sorry for delayed response.

On 2012/10/11, at 5:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> So I think we can't remove that functionality just yet. What we could
> do is adjust postgresql_fdw_validator to throw a WARNING that it's
> deprecated. This wouldn't prevent it from being used during dump/reload
> scenarios, but it would put people on notice that the code will be
> removed eventually. Without such a warning, it's not clear that we'll
> ever be able to remove it without getting complaints.

After reading discussion about deprecating RULE, I realized that we should
be conservative when changing existing user-visible behavior. Agreed that
we can't remove postgresql_fdw_validator without announcing for some
releases.

> However, I'm not sure where that leaves us with respect to the original
> goal of getting rid of use of that function name. Thoughts?

Sorry, I had misunderstood the problem :-(. In my proposal, postgresql_fdw
uses public schema, as other contrib modules do, so its validator can live
with existing pg_catalog.postgresql_fdw_validator. IMHO we should
remove postgresql_fdw_validator sooner or later, but we don't need to hurry
to remove existing postgresql_fdw_validator from core.

Of course we must ensure that postgresql_fdw never uses in-core validator,
and dblink and other product never use postgresql_fdw's validator. To
achieve this, how about to use a schema, say postgresql_fdw, for
postgresql_fdw by specifying "schema" option in extension control file?
We need to qualify function names, so relocatable should be false. This
requires users of postgresql_fdw to set search_path or qualify
postgresql_fdw's functions and views every time, but it seems acceptable.

In addition, this approach would prevent pollution of public schema.

Comments?

Regards,
--
Shigeru HANADA
shigeru(dot)hanada(at)gmail(dot)com