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

Re: Issue with libpq < 8.4

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Guillaume Lelarge <guillaume(at)lelarge(dot)info>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Issue with libpq < 8.4
Date: 2010-08-24 11:38:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
On Tue, Aug 24, 2010 at 12:32 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Tue, Aug 24, 2010 at 1:26 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> On Tue, Aug 24, 2010 at 12:20 PM, Guillaume Lelarge
>> <guillaume(at)lelarge(dot)info> wrote:
>>> Can't we just have it set a variable we could check with a #ifdef? We
>>> don't use PQconninfoParse in many files (actually, two). So it would be
>>> pretty easy to add the #ifdef line, so that it won't be a big issue for
>>> packagers.
>> We use PQconninfoParse to check to ensure we have a new enough libpq
>> to use application_name, so we can avoid sending it with older libpqs.
>> If we disable the check for older libpqs, then we'll always get an
>> error with them. The only way to fix that would be to only allow a 9.0
>> libpq to be used.
>> The current code at least allows 8.4 and 9.0 libpqs.
> What is it that we put into 8.4 that's making that one good enough? It
> still didn't actually know about application_name, did it? Or did we
> backpatch that knowledge, only not past 8.4?

PQconninfoParse is in 8.4 and above. we use that to test at runtime
whether or not we can use application_name.

Dave Page
Twitter: @pgsnake

EnterpriseDB UK:
The Enterprise Postgres Company

In response to


pgadmin-hackers by date

Next:From: Magnus HaganderDate: 2010-08-24 11:41:35
Subject: Re: Issue with libpq < 8.4
Previous:From: Dave PageDate: 2010-08-24 11:33:03
Subject: Re: Issue with libpq < 8.4

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