Sorry for delayed response.
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,
