Обсуждение: Issue with libpq < 8.4
Hi, I found a rather big issue with our connection functions. We try to use the PQconninfoParse but it doesn't exist on libpq release less than 8.4. And that triggers the deadly: pgadmin3: symbol lookup error: pgadmin3: undefined symbol: PQconninfoParse And kaboom. I don't think this issue will show up in Windows and Mac OS X. But I'm much more afraid for Linux builds. Someone that installs pgAdmin3 will have a libpq installed. Not sure it'll be the last one (8.4 libpq). can we tell packagers to make sure their pgadmin3 packages are tied to an 8.4 (at least) libpq? Is this something we should bother? and if yes, how should we handle this? (adding #ifdef won't work, getting out PQconninfoParse really doesn't please me). -- Guillaume http://www.postgresql.fr http://dalibo.com
Le 24/08/2010 11:49, Guillaume Lelarge a écrit : > Hi, > > I found a rather big issue with our connection functions. We try to use > the PQconninfoParse but it doesn't exist on libpq release less than 8.4. > And that triggers the deadly: > > pgadmin3: symbol lookup error: pgadmin3: undefined symbol: PQconninfoParse > > And kaboom. > > I don't think this issue will show up in Windows and Mac OS X. But I'm > much more afraid for Linux builds. Someone that installs pgAdmin3 will > have a libpq installed. Not sure it'll be the last one (8.4 libpq). can > we tell packagers to make sure their pgadmin3 packages are tied to an > 8.4 (at least) libpq? > > Is this something we should bother? and if yes, how should we handle > this? (adding #ifdef won't work, getting out PQconninfoParse really > doesn't please me). > > Of course, that's when I hit the Send button that I remember I forgot to add this: this issue is both on trunk and 1.12 branch. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Tue, Aug 24, 2010 at 10:52 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 24/08/2010 11:49, Guillaume Lelarge a écrit : >> Hi, >> >> I found a rather big issue with our connection functions. We try to use >> the PQconninfoParse but it doesn't exist on libpq release less than 8.4. >> And that triggers the deadly: >> >> pgadmin3: symbol lookup error: pgadmin3: undefined symbol: PQconninfoParse >> >> And kaboom. >> >> I don't think this issue will show up in Windows and Mac OS X. But I'm >> much more afraid for Linux builds. Someone that installs pgAdmin3 will >> have a libpq installed. Not sure it'll be the last one (8.4 libpq). can >> we tell packagers to make sure their pgadmin3 packages are tied to an >> 8.4 (at least) libpq? >> >> Is this something we should bother? and if yes, how should we handle >> this? (adding #ifdef won't work, getting out PQconninfoParse really >> doesn't please me). >> >> > > Of course, that's when I hit the Send button that I remember I forgot to > add this: this issue is both on trunk and 1.12 branch. Pretty simple to fix - just add a configure check for PQconninfoParse. I'll look at that. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Le 24/08/2010 11:54, Dave Page a écrit : > On Tue, Aug 24, 2010 at 10:52 AM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Le 24/08/2010 11:49, Guillaume Lelarge a écrit : >>> Hi, >>> >>> I found a rather big issue with our connection functions. We try to use >>> the PQconninfoParse but it doesn't exist on libpq release less than 8.4. >>> And that triggers the deadly: >>> >>> pgadmin3: symbol lookup error: pgadmin3: undefined symbol: PQconninfoParse >>> >>> And kaboom. >>> >>> I don't think this issue will show up in Windows and Mac OS X. But I'm >>> much more afraid for Linux builds. Someone that installs pgAdmin3 will >>> have a libpq installed. Not sure it'll be the last one (8.4 libpq). can >>> we tell packagers to make sure their pgadmin3 packages are tied to an >>> 8.4 (at least) libpq? >>> >>> Is this something we should bother? and if yes, how should we handle >>> this? (adding #ifdef won't work, getting out PQconninfoParse really >>> doesn't please me). >>> >>> >> >> Of course, that's when I hit the Send button that I remember I forgot to >> add this: this issue is both on trunk and 1.12 branch. > > Pretty simple to fix - just add a configure check for PQconninfoParse. > I'll look at that. > Adding a configure check doesn't seem that simple to me :) I suppose it'll fix packagers issue. I hope they use the required libraries when they build their packages. Really curious to see your patch. I've never had to change the configure stuff. Yet another thing to learn :) Thanks, Dave. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Tue, Aug 24, 2010 at 11:01 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Adding a configure check doesn't seem that simple to me :) If you can wrangle wxWidgets sizers, you can surely cope with a configure check :-) FYI, all the interesting stuff is in acinclude.m4. The bits that are called, and in what order comes from configure.ac.in. > I suppose it'll fix packagers issue. I hope they use the required > libraries when they build their packages. They'll have to now :-) > Really curious to see your patch. I've never had to change the configure > stuff. Yet another thing to learn :) http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
On Tue, Aug 24, 2010 at 12:28 PM, Dave Page <dpage@pgadmin.org> wrote: > On Tue, Aug 24, 2010 at 11:01 AM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Adding a configure check doesn't seem that simple to me :) > > If you can wrangle wxWidgets sizers, you can surely cope with a > configure check :-) > > FYI, all the interesting stuff is in acinclude.m4. The bits that are > called, and in what order comes from configure.ac.in. > >> I suppose it'll fix packagers issue. I hope they use the required >> libraries when they build their packages. > > They'll have to now :-) I'm pretty sure all the package building processes require that already. E.g. if you're building packages for squeeze, you'll have the -devel package from squeeze, etc. I'm more curios as to what we're doing if the function isn't present. What is it used for, and what will we do if it's not there? If we're going to end up importing the same functionality directly into pgadmin, we might as well use that one when we do.. Or do you mean a configure check that will refuse to build it if it's not there? > >> Really curious to see your patch. I've never had to change the configure >> stuff. Yet another thing to learn :) > > http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff Hmm, that answers my previous question. This "disqualifies" pgAdmin3 from quite a lot of platforms. There aren't that many that are on 8.4+ yet :-( -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Tue, Aug 24, 2010 at 11:49 AM, Magnus Hagander <magnus@hagander.net> wrote: > This "disqualifies" pgAdmin3 from quite a lot of platforms. There > aren't that many that are on 8.4+ yet :-( If the packagers are willing to update pgAdmin to 1.12, it seems highly likely that they'll also update their PostgreSQL package to 8.4+ too. The distros with a conservative update policy (like Debian Stable) won't update either. I'm pretty sure this was discussed in depth when the code was added... -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
On Tue, Aug 24, 2010 at 12:55 PM, Dave Page <dpage@pgadmin.org> wrote: > On Tue, Aug 24, 2010 at 11:49 AM, Magnus Hagander <magnus@hagander.net> > wrote: >> This "disqualifies" pgAdmin3 from quite a lot of platforms. There >> aren't that many that are on 8.4+ yet :-( > > If the packagers are willing to update pgAdmin to 1.12, it seems > highly likely that they'll also update their PostgreSQL package to > 8.4+ too. The distros with a conservative update policy (like Debian > Stable) won't update either. It's probably going to make it very hard for a backports repository to carry it though :( But I guess it could keep a backport of libpq as well, since it's always backwards compatible. > I'm pretty sure this was discussed in depth when the code was added... I must've missed that :-( Sorry. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Le 24/08/2010 13:01, Magnus Hagander a écrit : > On Tue, Aug 24, 2010 at 12:55 PM, Dave Page <dpage@pgadmin.org> wrote: >> On Tue, Aug 24, 2010 at 11:49 AM, Magnus Hagander <magnus@hagander.net> >> wrote: >>> This "disqualifies" pgAdmin3 from quite a lot of platforms. There >>> aren't that many that are on 8.4+ yet :-( >> >> If the packagers are willing to update pgAdmin to 1.12, it seems >> highly likely that they'll also update their PostgreSQL package to >> 8.4+ too. The distros with a conservative update policy (like Debian >> Stable) won't update either. > > It's probably going to make it very hard for a backports repository to > carry it though :( But I guess it could keep a backport of libpq as > well, since it's always backwards compatible. > 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. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Tue, Aug 24, 2010 at 12:20 PM, Guillaume Lelarge <guillaume@lelarge.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. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
On Tue, Aug 24, 2010 at 1:20 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 24/08/2010 13:01, Magnus Hagander a écrit : >> On Tue, Aug 24, 2010 at 12:55 PM, Dave Page <dpage@pgadmin.org> wrote: >>> On Tue, Aug 24, 2010 at 11:49 AM, Magnus Hagander <magnus@hagander.net> >>> wrote: >>>> This "disqualifies" pgAdmin3 from quite a lot of platforms. There >>>> aren't that many that are on 8.4+ yet :-( >>> >>> If the packagers are willing to update pgAdmin to 1.12, it seems >>> highly likely that they'll also update their PostgreSQL package to >>> 8.4+ too. The distros with a conservative update policy (like Debian >>> Stable) won't update either. >> >> It's probably going to make it very hard for a backports repository to >> carry it though :( But I guess it could keep a backport of libpq as >> well, since it's always backwards compatible. >> > > 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. Yeah, that's kind of what I was thinking. Sorry for re-opening this discussion, but is my reading correct that we are *only* using it to figure out if we have libpq version 9? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Tue, Aug 24, 2010 at 1:26 PM, Dave Page <dpage@pgadmin.org> wrote: > On Tue, Aug 24, 2010 at 12:20 PM, Guillaume Lelarge > <guillaume@lelarge.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? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Tue, Aug 24, 2010 at 12:29 PM, Magnus Hagander <magnus@hagander.net> wrote: > On Tue, Aug 24, 2010 at 1:20 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Le 24/08/2010 13:01, Magnus Hagander a écrit : >>> On Tue, Aug 24, 2010 at 12:55 PM, Dave Page <dpage@pgadmin.org> wrote: >>>> On Tue, Aug 24, 2010 at 11:49 AM, Magnus Hagander <magnus@hagander.net> >>>> wrote: >>>>> This "disqualifies" pgAdmin3 from quite a lot of platforms. There >>>>> aren't that many that are on 8.4+ yet :-( >>>> >>>> If the packagers are willing to update pgAdmin to 1.12, it seems >>>> highly likely that they'll also update their PostgreSQL package to >>>> 8.4+ too. The distros with a conservative update policy (like Debian >>>> Stable) won't update either. >>> >>> It's probably going to make it very hard for a backports repository to >>> carry it though :( But I guess it could keep a backport of libpq as >>> well, since it's always backwards compatible. >>> >> >> 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. > > Yeah, that's kind of what I was thinking. Sorry for re-opening this > discussion, but is my reading correct that we are *only* using it to > figure out if we have libpq version 9? Essentially, yes. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
On Tue, Aug 24, 2010 at 12:32 PM, Magnus Hagander <magnus@hagander.net> wrote: > On Tue, Aug 24, 2010 at 1:26 PM, Dave Page <dpage@pgadmin.org> wrote: >> On Tue, Aug 24, 2010 at 12:20 PM, Guillaume Lelarge >> <guillaume@lelarge.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 Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
On Tue, Aug 24, 2010 at 1:38 PM, Dave Page <dpage@pgadmin.org> wrote: > On Tue, Aug 24, 2010 at 12:32 PM, Magnus Hagander <magnus@hagander.net> > wrote: >> On Tue, Aug 24, 2010 at 1:26 PM, Dave Page <dpage@pgadmin.org> wrote: >>> On Tue, Aug 24, 2010 at 12:20 PM, Guillaume Lelarge >>> <guillaume@lelarge.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. Oh. Meh, we didn't have it at all before that. Forgot about that :S So can't we do something like: #ifdef HAVE_CONNINFO_PARSE if (conninfoparse_shows_we_have_application_name_support) use connstr_with_appname; else use connstr_without_appname; #else use connstr_without_appname #endif ? That way it should still work with older libpq, just not set application_name... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Tue, Aug 24, 2010 at 12:41 PM, Magnus Hagander <magnus@hagander.net> wrote: > So can't we do something like: > > #ifdef HAVE_CONNINFO_PARSE > if (conninfoparse_shows_we_have_application_name_support) > use connstr_with_appname; > else > use connstr_without_appname; > #else > use connstr_without_appname > #endif > > ? That way it should still work with older libpq, just not set > application_name... That would probably work. We should probably have a runtime check for Windows, as we do for the EDB libpq functions. When can I expect the patch? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
On Tue, Aug 24, 2010 at 1:45 PM, Dave Page <dpage@pgadmin.org> wrote: > On Tue, Aug 24, 2010 at 12:41 PM, Magnus Hagander <magnus@hagander.net> > wrote: >> So can't we do something like: >> >> #ifdef HAVE_CONNINFO_PARSE >> if (conninfoparse_shows_we_have_application_name_support) >> use connstr_with_appname; >> else >> use connstr_without_appname; >> #else >> use connstr_without_appname >> #endif >> >> ? That way it should still work with older libpq, just not set >> application_name... > > That would probably work. We should probably have a runtime check for > Windows, as we do for the EDB libpq functions. Yeah, that's probably a good idea. Actually, what happens if we try to use PQconnect() with applicaiton_name on an older version? I assume it fails, and not just works and ignores it? > When can I expect the patch? What's with you edb folks, trying to get me to write your patches? Yesterday Haas, today you... Shall I expect a mail from Ed? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Tue, Aug 24, 2010 at 12:48 PM, Magnus Hagander <magnus@hagander.net> wrote: > Actually, what happens if we try to use PQconnect() with > applicaiton_name on an older version? I assume it fails, and not just > works and ignores it? iirc, yes. > >> When can I expect the patch? > > What's with you edb folks, trying to get me to write your patches? > Yesterday Haas, today you... Shall I expect a mail from Ed? I can arrange that if you'd like? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Le 24/08/2010 13:51, Dave Page a écrit : > On Tue, Aug 24, 2010 at 12:48 PM, Magnus Hagander <magnus@hagander.net> wrote: >> Actually, what happens if we try to use PQconnect() with >> applicaiton_name on an older version? I assume it fails, and not just >> works and ignores it? > > iirc, yes. > We have this in the log: FATAL: unrecognized configuration parameter "application_name" And then it connects. At least with a 9.0 libpq and a 8.3.0 PostgreSQL server. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Tue, Aug 24, 2010 at 2:01 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 24/08/2010 13:51, Dave Page a écrit : >> On Tue, Aug 24, 2010 at 12:48 PM, Magnus Hagander <magnus@hagander.net> >> wrote: >>> Actually, what happens if we try to use PQconnect() with >>> applicaiton_name on an older version? I assume it fails, and not just >>> works and ignores it? >> >> iirc, yes. >> > > We have this in the log: > > FATAL: unrecognized configuration parameter "application_name" > > And then it connects. > > At least with a 9.0 libpq and a 8.3.0 PostgreSQL server. Yeah, the interesting thing would be an 8.3 libpq, if you just throw it the connection string and don't try to use PQparseconnInfo(). -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Le 24/08/2010 14:05, Magnus Hagander a écrit : > On Tue, Aug 24, 2010 at 2:01 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Le 24/08/2010 13:51, Dave Page a écrit : >>> On Tue, Aug 24, 2010 at 12:48 PM, Magnus Hagander <magnus@hagander.net> >>> wrote: >>>> Actually, what happens if we try to use PQconnect() with >>>> applicaiton_name on an older version? I assume it fails, and not just >>>> works and ignores it? >>> >>> iirc, yes. >>> >> >> We have this in the log: >> >> FATAL: unrecognized configuration parameter "application_name" >> >> And then it connects. >> >> At least with a 9.0 libpq and a 8.3.0 PostgreSQL server. > > Yeah, the interesting thing would be an 8.3 libpq, if you just throw > it the connection string and don't try to use PQparseconnInfo(). > It fails. If the user has a 8.3 libpq, we should not send the application_name connection parameter. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Tue, Aug 24, 2010 at 2:23 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 24/08/2010 14:05, Magnus Hagander a écrit : >> On Tue, Aug 24, 2010 at 2:01 PM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >>> Le 24/08/2010 13:51, Dave Page a écrit : >>>> On Tue, Aug 24, 2010 at 12:48 PM, Magnus Hagander <magnus@hagander.net> >>>> wrote: >>>>> Actually, what happens if we try to use PQconnect() with >>>>> applicaiton_name on an older version? I assume it fails, and not just >>>>> works and ignores it? >>>> >>>> iirc, yes. >>>> >>> >>> We have this in the log: >>> >>> FATAL: unrecognized configuration parameter "application_name" >>> >>> And then it connects. >>> >>> At least with a 9.0 libpq and a 8.3.0 PostgreSQL server. >> >> Yeah, the interesting thing would be an 8.3 libpq, if you just throw >> it the connection string and don't try to use PQparseconnInfo(). >> > > It fails. If the user has a 8.3 libpq, we should not send the > application_name connection parameter. That means Dave is perfectly correct, and thus someone needs to write that patch ;) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Le 24/08/2010 15:25, Magnus Hagander a écrit : > On Tue, Aug 24, 2010 at 2:23 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Le 24/08/2010 14:05, Magnus Hagander a écrit : >>> On Tue, Aug 24, 2010 at 2:01 PM, Guillaume Lelarge >>> <guillaume@lelarge.info> wrote: >>>> Le 24/08/2010 13:51, Dave Page a écrit : >>>>> On Tue, Aug 24, 2010 at 12:48 PM, Magnus Hagander <magnus@hagander.net> >>>>> wrote: >>>>>> Actually, what happens if we try to use PQconnect() with >>>>>> applicaiton_name on an older version? I assume it fails, and not just >>>>>> works and ignores it? >>>>> >>>>> iirc, yes. >>>>> >>>> >>>> We have this in the log: >>>> >>>> FATAL: unrecognized configuration parameter "application_name" >>>> >>>> And then it connects. >>>> >>>> At least with a 9.0 libpq and a 8.3.0 PostgreSQL server. >>> >>> Yeah, the interesting thing would be an 8.3 libpq, if you just throw >>> it the connection string and don't try to use PQparseconnInfo(). >>> >> >> It fails. If the user has a 8.3 libpq, we should not send the >> application_name connection parameter. > > That means Dave is perfectly correct, and thus someone needs to write > that patch ;) > What I've come to is this patch. Actually, and quite surprisingly, it doesn't work. I have no idea why. The configure script finds if we have or not the PQconninfoParse function(), but the #ifdef in pgConn source file doesn't seem to do what it has to. I always get a build without PQconninfoParse, wether configure founds it or not. Any ideas on what I did wrong? -- Guillaume http://www.postgresql.fr http://dalibo.com
On Thu, Aug 26, 2010 at 10:48 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > What I've come to is this patch. Actually, and quite surprisingly, it > doesn't work. I have no idea why. The configure script finds if we have > or not the PQconninfoParse function(), but the #ifdef in pgConn source > file doesn't seem to do what it has to. I always get a build without > PQconninfoParse, wether configure founds it or not. > > Any ideas on what I did wrong? EPATCHNOTFOUND -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Le 26/08/2010 11:49, Dave Page a écrit : > On Thu, Aug 26, 2010 at 10:48 AM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> What I've come to is this patch. Actually, and quite surprisingly, it >> doesn't work. I have no idea why. The configure script finds if we have >> or not the PQconninfoParse function(), but the #ifdef in pgConn source >> file doesn't seem to do what it has to. I always get a build without >> PQconninfoParse, wether configure founds it or not. >> >> Any ideas on what I did wrong? > > EPATCHNOTFOUND > Oops, time to get some coffee, as you already said :) -- Guillaume http://www.postgresql.fr http://dalibo.com
Вложения
On Thu, Aug 26, 2010 at 10:51 AM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> Le 26/08/2010 11:49, Dave Page a écrit :
>> On Thu, Aug 26, 2010 at 10:48 AM, Guillaume Lelarge
>> <guillaume@lelarge.info> wrote:
>>> What I've come to is this patch. Actually, and quite surprisingly, it
>>> doesn't work. I have no idea why. The configure script finds if we have
>>> or not the PQconninfoParse function(), but the #ifdef in pgConn source
>>> file doesn't seem to do what it has to. I always get a build without
>>> PQconninfoParse, wether configure founds it or not.
>>>
>>> Any ideas on what I did wrong?
>>
>> EPATCHNOTFOUND
>>
>
> Oops, time to get some coffee, as you already said :)
There's two ways you can fix it. To match what we do for SSL support:
In acinclude.m4, you don't need to use AC_SUBST, and you do need to
add something like:
if test "$PG_SSL" = "yes"
then
CPPFLAGS="$CPPFLAGS -DSSL"
fi
but for HAVE_CONNINFOPARSE (yes, I know we should probably do this in
CXXFLAGS, but now is not the time to fix the build system :-p ).
The other way uses AC_SUBST to add the variable to the Makefile (which
you did). You can then use that variable in Makefile.am to
conditionally add the -DHAVE_CONNINFOPARSE. Iirc, that's similar to
have we deal with the options to build an appbundle.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company
Le 26/08/2010 12:15, Magnus Hagander a écrit : > On Thu, Aug 26, 2010 at 12:02, Dave Page <dpage@pgadmin.org> wrote: >> On Thu, Aug 26, 2010 at 10:51 AM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >>> Le 26/08/2010 11:49, Dave Page a écrit : >>>> On Thu, Aug 26, 2010 at 10:48 AM, Guillaume Lelarge >>>> <guillaume@lelarge.info> wrote: >>>>> What I've come to is this patch. Actually, and quite surprisingly, it >>>>> doesn't work. I have no idea why. The configure script finds if we have >>>>> or not the PQconninfoParse function(), but the #ifdef in pgConn source >>>>> file doesn't seem to do what it has to. I always get a build without >>>>> PQconninfoParse, wether configure founds it or not. >>>>> >>>>> Any ideas on what I did wrong? >>>> >>>> EPATCHNOTFOUND >>>> >>> >>> Oops, time to get some coffee, as you already said :) >> >> There's two ways you can fix it. To match what we do for SSL support: >> >> In acinclude.m4, you don't need to use AC_SUBST, and you do need to >> add something like: >> >> if test "$PG_SSL" = "yes" >> then >> CPPFLAGS="$CPPFLAGS -DSSL" >> fi >> >> but for HAVE_CONNINFOPARSE (yes, I know we should probably do this in >> CXXFLAGS, but now is not the time to fix the build system :-p ). >> >> The other way uses AC_SUBST to add the variable to the Makefile (which >> you did). You can then use that variable in Makefile.am to >> conditionally add the -DHAVE_CONNINFOPARSE. Iirc, that's similar to >> have we deal with the options to build an appbundle. > OK, great. Thanks. I used the former, more simple to me. Patch attached. > Completely uninformed question: > how does that work out wrt the VC project files? > I have absolutely no idea. But a quick look doesn't even get anything about how PG_SSL is handled by the VC project files. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Thu, Aug 26, 2010 at 12:02, Dave Page <dpage@pgadmin.org> wrote: > On Thu, Aug 26, 2010 at 10:51 AM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Le 26/08/2010 11:49, Dave Page a écrit : >>> On Thu, Aug 26, 2010 at 10:48 AM, Guillaume Lelarge >>> <guillaume@lelarge.info> wrote: >>>> What I've come to is this patch. Actually, and quite surprisingly, it >>>> doesn't work. I have no idea why. The configure script finds if we have >>>> or not the PQconninfoParse function(), but the #ifdef in pgConn source >>>> file doesn't seem to do what it has to. I always get a build without >>>> PQconninfoParse, wether configure founds it or not. >>>> >>>> Any ideas on what I did wrong? >>> >>> EPATCHNOTFOUND >>> >> >> Oops, time to get some coffee, as you already said :) > > There's two ways you can fix it. To match what we do for SSL support: > > In acinclude.m4, you don't need to use AC_SUBST, and you do need to > add something like: > > if test "$PG_SSL" = "yes" > then > CPPFLAGS="$CPPFLAGS -DSSL" > fi > > but for HAVE_CONNINFOPARSE (yes, I know we should probably do this in > CXXFLAGS, but now is not the time to fix the build system :-p ). > > The other way uses AC_SUBST to add the variable to the Makefile (which > you did). You can then use that variable in Makefile.am to > conditionally add the -DHAVE_CONNINFOPARSE. Iirc, that's similar to > have we deal with the options to build an appbundle. Completely uninformed question: how does that work out wrt the VC project files? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Thu, Aug 26, 2010 at 11:15 AM, Magnus Hagander <magnus@hagander.net> wrote: > On Thu, Aug 26, 2010 at 12:02, Dave Page <dpage@pgadmin.org> wrote: >> On Thu, Aug 26, 2010 at 10:51 AM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >>> Le 26/08/2010 11:49, Dave Page a écrit : >>>> On Thu, Aug 26, 2010 at 10:48 AM, Guillaume Lelarge >>>> <guillaume@lelarge.info> wrote: >>>>> What I've come to is this patch. Actually, and quite surprisingly, it >>>>> doesn't work. I have no idea why. The configure script finds if we have >>>>> or not the PQconninfoParse function(), but the #ifdef in pgConn source >>>>> file doesn't seem to do what it has to. I always get a build without >>>>> PQconninfoParse, wether configure founds it or not. >>>>> >>>>> Any ideas on what I did wrong? >>>> >>>> EPATCHNOTFOUND >>>> >>> >>> Oops, time to get some coffee, as you already said :) >> >> There's two ways you can fix it. To match what we do for SSL support: >> >> In acinclude.m4, you don't need to use AC_SUBST, and you do need to >> add something like: >> >> if test "$PG_SSL" = "yes" >> then >> CPPFLAGS="$CPPFLAGS -DSSL" >> fi >> >> but for HAVE_CONNINFOPARSE (yes, I know we should probably do this in >> CXXFLAGS, but now is not the time to fix the build system :-p ). >> >> The other way uses AC_SUBST to add the variable to the Makefile (which >> you did). You can then use that variable in Makefile.am to >> conditionally add the -DHAVE_CONNINFOPARSE. Iirc, that's similar to >> have we deal with the options to build an appbundle. > > Completely uninformed question: > how does that work out wrt the VC project files? It doesn't. With the EDB libpq extensions, we do a runtime test to see if they're there, and then use function pointers if so. We could possibly do the same here, though as there are so few people building their own Windows versions, I'm not sure it's worth it. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
On Thu, Aug 26, 2010 at 11:24 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > I have absolutely no idea. But a quick look doesn't even get anything > about how PG_SSL is handled by the VC project files. It's not - we assume the user is using our installers which always have SSL support. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Le 26/08/2010 12:31, Dave Page a écrit : > On Thu, Aug 26, 2010 at 11:24 AM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> I have absolutely no idea. But a quick look doesn't even get anything >> about how PG_SSL is handled by the VC project files. > > It's not - we assume the user is using our installers which always > have SSL support. > > OK. I've commited my patch. I think I'm mostly done, at least for a RC tomorrow morning. I now have to send an email to our translators. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Thu, Aug 26, 2010 at 12:31 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 26/08/2010 12:31, Dave Page a écrit : >> On Thu, Aug 26, 2010 at 11:24 AM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >>> I have absolutely no idea. But a quick look doesn't even get anything >>> about how PG_SSL is handled by the VC project files. >> >> It's not - we assume the user is using our installers which always >> have SSL support. >> >> > > OK. I've commited my patch. I think I'm mostly done, at least for a RC > tomorrow morning. I now have to send an email to our translators. Great - thanks! -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company