Thread

  1. ecpglib use PQconnectdbParams

    Peter Eisentraut <peter_e@gmx.net> — 2012-02-02T18:01:48Z

    I noticed ecpglib still uses PQconnectdb() with a craftily assembled
    connection string.  Here is a patch to use PQconnectdbParams() instead.
    
  2. Re: ecpglib use PQconnectdbParams

    Christian Ullrich <chris@chrullrich.net> — 2012-02-03T12:15:30Z

    * Peter Eisentraut wrote:
    
    > I noticed ecpglib still uses PQconnectdb() with a craftily assembled
    > connection string.  Here is a patch to use PQconnectdbParams() instead.
    
    +	const char *conn_keywords[6];
    +	const char *conn_values[6];
    
    Shouldn't these be [7]? You can have up to 6 items, plus the terminator.
    
    -- 
    Christian Ullrich
    
    
    
    
  3. Re: ecpglib use PQconnectdbParams

    Michael Meskes <meskes@postgresql.org> — 2012-02-03T16:48:08Z

    On Thu, Feb 02, 2012 at 08:01:48PM +0200, Peter Eisentraut wrote:
    > I noticed ecpglib still uses PQconnectdb() with a craftily assembled
    > connection string.  Here is a patch to use PQconnectdbParams() instead.
    
    Thanks, committed. Will sync as soon as I'm online again.
    
    Michael
    -- 
    Michael Meskes
    Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
    Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
    Jabber: michael.meskes at googlemail dot com
    VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
    
    
  4. Re: ecpglib use PQconnectdbParams

    Marko Kreen <markokr@gmail.com> — 2012-02-06T16:50:44Z

    On Fri, Feb 03, 2012 at 01:15:30PM +0100, Christian Ullrich wrote:
    > * Peter Eisentraut wrote:
    > >I noticed ecpglib still uses PQconnectdb() with a craftily assembled
    > >connection string.  Here is a patch to use PQconnectdbParams() instead.
    > 
    > +	const char *conn_keywords[6];
    > +	const char *conn_values[6];
    > 
    > Shouldn't these be [7]? You can have up to 6 items, plus the terminator.
    
    This bug is now in GIT.
    
    -- 
    marko
    
    
    
  5. Re: ecpglib use PQconnectdbParams

    Michael Meskes <meskes@postgresql.org> — 2012-02-06T20:11:32Z

    On Fri, Feb 03, 2012 at 01:15:30PM +0100, Christian Ullrich wrote:
    > Shouldn't these be [7]? You can have up to 6 items, plus the terminator.
    
    I take it only keywords have to be [7], right? Committed, thanks for spotting this.
    
    There seems to be one more problem that I haven't had time to tackle yet. With
    this patch the connection regression test (make checktcp) doesn't run through
    anymore because one test connection cannot be made. It spits out the error
    message:
    
    FATAL:  invalid command-line arguments for server process 
    HINT:  Try "postgres --help" for more information.
    
    This connection used to work without the patch and besides the error message is
    not really telling in this context.
    
    So if anyone is interested in looking at this fine, if not I will as soon as I
    find some spare time.
    
    Michael
    -- 
    Michael Meskes
    Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
    Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
    Jabber: michael.meskes at googlemail dot com
    VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
    
    
  6. Re: ecpglib use PQconnectdbParams

    Peter Eisentraut <peter_e@gmx.net> — 2012-02-08T12:47:01Z

    On mån, 2012-02-06 at 21:11 +0100, Michael Meskes wrote:
    > On Fri, Feb 03, 2012 at 01:15:30PM +0100, Christian Ullrich wrote:
    > > Shouldn't these be [7]? You can have up to 6 items, plus the terminator.
    > 
    > I take it only keywords have to be [7], right? Committed, thanks for spotting this.
    > 
    > There seems to be one more problem that I haven't had time to tackle yet. With
    > this patch the connection regression test (make checktcp) doesn't run through
    > anymore because one test connection cannot be made. It spits out the error
    > message:
    > 
    > FATAL:  invalid command-line arguments for server process 
    > HINT:  Try "postgres --help" for more information.
    > 
    > This connection used to work without the patch and besides the error message is
    > not really telling in this context.
    
    You can get more information on that with the attached patch, which
    might be a useful addition in general.  The problem comes from this:
    
    exec sql connect to unix:postgresql://localhost/connectdb?connect_timeout=14 user connectuser;
    
    and the updated error message is:
    
    ECPGconnect: could not open database: FATAL:  invalid command-line arguments for server process: connect_timeout=14
    
    Because connect_timeout is a separate libpq connection parameter, but
    now it's stuck into "options".  It might have worked more or less by
    accident before.
    
    It's not clear to me why this only appears on checktcp.  And why we
    don't run those tests by default.  That should be clarified, because
    there are also other failures in that test that show that it hasn't been
    run in a while.
    
    
  7. Re: ecpglib use PQconnectdbParams

    Tom Lane <tgl@sss.pgh.pa.us> — 2012-02-08T15:19:40Z

    Peter Eisentraut <peter_e@gmx.net> writes:
    >  		if (IsUnderPostmaster)
    >  			ereport(FATAL,
    >  					(errcode(ERRCODE_SYNTAX_ERROR),
    > -				 errmsg("invalid command-line arguments for server process"),
    > +				 errmsg("invalid command-line arguments for server process: %s", argv[optind]),
    >  			  errhint("Try \"%s --help\" for more information.", progname)));
    >  		else
    >  			ereport(FATAL,
    
    +1 for that change, but please s/arguments/argument/ in the text.  Also,
    what about the other branch of the "if" that's just out of sight here?
    
    			regards, tom lane
    
    
  8. Re: ecpglib use PQconnectdbParams

    Michael Meskes <meskes@postgresql.org> — 2012-02-13T11:21:46Z

    > Because connect_timeout is a separate libpq connection parameter, but
    > now it's stuck into "options".  It might have worked more or less by
    > accident before.
    
    So it is not an option, right? But the old function accepted it as an option it seems.
    
    > It's not clear to me why this only appears on checktcp.  And why we
    > don't run those tests by default.  That should be clarified, because
    
    This was decided when regression tests for ecpg were introduced to not depend
    on the use of TCP ports.
    
    For details see this thread:
    http://archives.postgresql.org/pgsql-hackers/2006-08/msg00078.php
    and in particular these emails: 
    http://archives.postgresql.org/pgsql-hackers/2006-08/msg00118.php
    http://archives.postgresql.org/pgsql-hackers/2006-08/msg00134.php
    
    Michael
    -- 
    Michael Meskes
    Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
    Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
    Jabber: michael.meskes at googlemail dot com
    VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL