2013/1/18 Craig Ringer :
> On 11/16/2012 08:08 AM, Noah Misch wrote:
>
> On Thu, Nov 15, 2012 at 02:33:21PM +0900, Shigeru Hanada wrote:
>
> On Sat, Oct 20, 2012 at 4:24 PM, Kohei KaiGai wrote:
>
> IIRC, the reason why postgresql_fdw instead of pgsql_fdw was
> no other fdw module has shorten namin
On 11/16/2012 08:08 AM, Noah Misch wrote:
> On Thu, Nov 15, 2012 at 02:33:21PM +0900, Shigeru Hanada wrote:
>> On Sat, Oct 20, 2012 at 4:24 PM, Kohei KaiGai wrote:
>>> IIRC, the reason why postgresql_fdw instead of pgsql_fdw was
>>> no other fdw module has shorten naming such as ora_fdw for
>>> Or
On Thu, Nov 15, 2012 at 02:33:21PM +0900, Shigeru Hanada wrote:
> On Sat, Oct 20, 2012 at 4:24 PM, Kohei KaiGai wrote:
> > 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 enou
Sorry for long absence.
On Sat, Oct 20, 2012 at 4:24 PM, Kohei KaiGai wrote:
> 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 technica
Sorry for long absence.
On Sat, Oct 20, 2012 at 4:24 PM, Kohei KaiGai wrote:
> 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 technica
2012/10/19 Robert Haas :
> On Fri, Oct 19, 2012 at 7:17 AM, Shigeru HANADA
> 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, postgres
On Fri, Oct 19, 2012 at 7:17 AM, Shigeru HANADA
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 o
Sorry for delayed response.
On 2012/10/11, at 5:28, Tom Lane 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,
Shigeru HANADA writes:
> [ dblink_fdw_validator.v3.patch ]
I've committed the dblink portion of this with some mostly-cosmetic
adjustments. We still need a plan for getting to a point where it's
safe to remove postgresql_fdw_validator.
regards, tom lane
--
Sent via pg
Shigeru HANADA writes:
> (2012/10/09 0:30), Kohei KaiGai wrote:
>> If it is also OK for you, I'd like to take over this patch to comitter.
>> This patch is prerequisite of postgresql_fdw, so I hope this patch
>> getting merged soon.
> Please go ahead. :-)
While reviewing this patch, I realized t
Hanada-san,
It is fair enough for me.
So, I'd like to hand over this patch for committers.
Thanks,
2012/10/9 Shigeru HANADA :
> (2012/10/09 0:30), Kohei KaiGai wrote:
>>
>> The attached patch is a revised one according to my previous
>> suggestion. It re-defines "PQconninfoOption *options" as st
(2012/10/09 0:30), Kohei KaiGai wrote:
The attached patch is a revised one according to my previous
suggestion. It re-defines "PQconninfoOption *options" as static
variable with NULL initial value, then, PQconndefaults() shall
be invoked at once. The default options never changed during
duration
Hanada-san,
The attached patch is a revised one according to my previous
suggestion. It re-defines "PQconninfoOption *options" as static
variable with NULL initial value, then, PQconndefaults() shall
be invoked at once. The default options never changed during
duration of the backend process, so h
Hanada-san,
I checked your patch. It can be applied to the latest master branch
without any conflicts, and regression tests were fine.
Unlike the original postgresql_fdw_validator(), the new
dblink_fdw_validator() has wise idea; that pulls list of connection
options from libpq, instead of self-de
Kaigai-san,
(2012/09/13 16:56), Kohei KaiGai wrote:
> What about your plan to upstream contrib/pgsql_fdw module on the upcoming
> commit-fest?
I will post pgsql_fdw patch (though it will be renamed to
postgresql_fdw) in opening CF (2012 Sep), as soon as I resolve a bug in
ANALYZE support, maybe o
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 o
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
17 matches
Mail list logo
