Skip site navigation (1) Skip section navigation (2)

Re: Streaming Replication on win32

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming Replication on win32
Date: 2010-01-22 07:19:06
Message-ID: 4B59516A.5050906@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Joe Conway wrote:
> OK, so now I see why we want this fixed for dblink and walreceiver, but
> doesn't this approach leave every other WIN32 libpq client out in the
> cold? Is there nothing that can be done for the general case, or is it a
> SMOP?

The problem only applies to libpq calls from the backend. Client apps
are not affected, only backend modules. If there's any other modules out
there that use libpq, then yes, those have a problem too.

A generic fix would be nice. Putting the wrapper functions in a new
header file that's included in all backend modules that want to use
libpq would work. Maybe the new header file could even be #included from
libpq-fe.h, when compiling backend code (#ifndef FRONTEND), so you
wouldn't need to modify dblink, walreceiver, or any 3rd party modules
that use libpq at all.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Andreas Joseph KroghDate: 2010-01-22 08:06:13
Subject: Re: 8.5 vs. 9.0
Previous:From: Pavel StehuleDate: 2010-01-22 07:16:29
Subject: Re: quoting psql varible as identifier

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group