Re: Move postgresql_fdw_validator into dblink

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Shigeru HANADA <shigeru(dot)hanada(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Move postgresql_fdw_validator into dblink
Date: 2012-10-20 07:24:35
Message-ID: CADyhKSVWwndQ7t0Kgb+86NB69iub0RyXtYr+TBA49PRZJgscnQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2012/10/19 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Fri, Oct 19, 2012 at 7:17 AM, Shigeru HANADA
> <shigeru(dot)hanada(at)gmail(dot)com> wrote:
>> 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.
>
> It seems to me that this is a case of the tail wagging the dog. The
> original reason we ran into this issue is because there were some
> people (I forget who, sorry) who insisted that this had to be renamed
> from pgsql_fdw to postgresql_fdw. That change then caused this naming
> conflict. Now, normally what we do if we have a naming conflict is we
> rename one of the two things so that we don't have a naming conflict.
> If we've determined that we can't rename postgresql_fdw_validator for
> reasons of backward compatibility, then we should rename this new
> thing instead. We of course do not have to use the original
> pgsql_fdw_validator name; it can be postgres_fdw_validator or
> postgree_fdw_validator or prostgreskewell_fdw_validator or whatever
> the consensus bikeshed position is.
>
IIRC, the reason why postgresql_fdw instead of pgsql_fdw was
no other fdw module has shorten naming such as ora_fdw for
Oracle.
However, I doubt whether it is enough strong reason to force to
solve the technical difficulty; naming conflicts with existing user
visible features.
Isn't it worth to consider to back to the pgsql_fdw_validator
naming again?

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-10-20 09:26:31 Re: Foreign key constraint on sub-column of composite-type column
Previous Message Abhijit Menon-Sen 2012-10-20 07:19:03 Re: patch to add \watch to psql