Sorry for delayed response. On 2012/10/11, at 5:28, Tom Lane <t...@sss.pgh.pa.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.han...@gmail.com
