Using the new libpq connection functions in PostgreSQL binaries

Lists: pgsql-hackers
From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Using the new libpq connection functions in PostgreSQL binaries
Date: 2010-01-31 08:34:32
Message-ID: 4B654098.5000807@lelarge.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi,

I worked on a patch to make PostgreSQL binaries use the new
PQconnectdbParams() libpq functions. I tried to mimic the way Joe Conway
changed my previous patch.

I know I'm way over the deadline for this commitfest. I couldn't do it
before because my previous patch (on this commit fest) proposed two
methods to do the new connection functions (a one array method, and a
two-arrays method). Joe chose the two arrays method. Anyways, I would
understand if it gets postponed to the first commitfest for 9.1.

Regards.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Attachment Content-Type Size
appname.patch text/x-patch 13.7 KB

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using the new libpq connection functions in PostgreSQL binaries
Date: 2010-01-31 12:39:25
Message-ID: 9837222c1001310439y38545012t68e6a4762b5d64f8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Sun, Jan 31, 2010 at 09:34, Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
> Hi,
>
> I worked on a patch to make PostgreSQL binaries use the new
> PQconnectdbParams() libpq functions. I tried to mimic the way Joe Conway
> changed my previous patch.
>
> I know I'm way over the deadline for this commitfest. I couldn't do it
> before because my previous patch (on this commit fest) proposed two
> methods to do the new connection functions (a one array method, and a
> two-arrays method). Joe chose the two arrays method. Anyways, I would
> understand if it gets postponed to the first commitfest for 9.1.

I think this can reasonably be seen as the final step of that patch,
rather than a completely new feature. Please add it to this CF - we
can always remove it if too many others object ;)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/


From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using the new libpq connection functions in PostgreSQL binaries
Date: 2010-01-31 12:48:24
Message-ID: 4B657C18.6020400@lelarge.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Le 31/01/2010 13:39, Magnus Hagander a écrit :
> On Sun, Jan 31, 2010 at 09:34, Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
>> Hi,
>>
>> I worked on a patch to make PostgreSQL binaries use the new
>> PQconnectdbParams() libpq functions. I tried to mimic the way Joe Conway
>> changed my previous patch.
>>
>> I know I'm way over the deadline for this commitfest. I couldn't do it
>> before because my previous patch (on this commit fest) proposed two
>> methods to do the new connection functions (a one array method, and a
>> two-arrays method). Joe chose the two arrays method. Anyways, I would
>> understand if it gets postponed to the first commitfest for 9.1.
>
> I think this can reasonably be seen as the final step of that patch,
> rather than a completely new feature. Please add it to this CF - we
> can always remove it if too many others object ;)
>

Done (https://commitfest.postgresql.org/action/patch_view?id=278). Thanks.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Using the new libpq connection functions in PostgreSQL binaries
Date: 2010-01-31 16:35:49
Message-ID: 25604.1264955749@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:

> */
> do
> {
> + const char *values[] = {
> + my_opts->hostname,
> + my_opts->port,
> + my_opts->dbname,
> + my_opts->username,
> + password,
> + "oid2name",
> + NULL
> + };
> +
> new_pass = false;

Is that really legal C89 syntax? I seem to recall that array
constructors can only be used for static assignments with older
compilers.

Also, as a matter of style, I find it pretty horrid that this isn't
immediately adjacent to the keywords array that it MUST match.

regards, tom lane


From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Using the new libpq connection functions in PostgreSQL binaries
Date: 2010-01-31 17:42:50
Message-ID: 4B65C11A.7010405@lelarge.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Le 31/01/2010 17:35, Tom Lane a écrit :
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
>
>> */
>> do
>> {
>> + const char *values[] = {
>> + my_opts->hostname,
>> + my_opts->port,
>> + my_opts->dbname,
>> + my_opts->username,
>> + password,
>> + "oid2name",
>> + NULL
>> + };
>> +
>> new_pass = false;
>
> Is that really legal C89 syntax?

I don't really know. gcc (4.4.1 release) didn't complain about it,
whereas it complained with a warning for not-legal-syntax when I had the
"new_pass = false;" statement before the array declaration.

> I seem to recall that array
> constructors can only be used for static assignments with older
> compilers.
>
> Also, as a matter of style, I find it pretty horrid that this isn't
> immediately adjacent to the keywords array that it MUST match.
>

I don't find that horrid. AFAICT, that's the only advantage of the
two-arrays method. By the way, it's that kind of code (keywords
declaration separated from values declaration) that got commited in the
previous patch
(http://archives.postgresql.org/pgsql-committers/2010-01/msg00398.php).
I merely used the same code for the other binaries.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com


From: Joe Conway <mail(at)joeconway(dot)com>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Using the new libpq connection functions in PostgreSQL binaries
Date: 2010-01-31 17:51:05
Message-ID: 4B65C309.9080007@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 01/31/2010 09:42 AM, Guillaume Lelarge wrote:
> I don't find that horrid. AFAICT, that's the only advantage of the
> two-arrays method. By the way, it's that kind of code (keywords
> declaration separated from values declaration) that got commited in the
> previous patch
> (http://archives.postgresql.org/pgsql-committers/2010-01/msg00398.php).
> I merely used the same code for the other binaries.

Yes, I separated them, because otherwise the compiler complained about
the declaration not being at the top of a block. Of course Tom's other
complaint and this one can both be satisfied by not doing the static
assignment in the declaration.

I'll fix the already committed code and take a look at refactoring this
latest patch. I stand by the two arrays mthod decision though -- I find
combining them into a single array to be unseemly.

Joe


From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Using the new libpq connection functions in PostgreSQL binaries
Date: 2010-02-02 18:25:21
Message-ID: 1265135121.9121.0.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On sön, 2010-01-31 at 09:34 +0100, Guillaume Lelarge wrote:
> I worked on a patch to make PostgreSQL binaries use the new
> PQconnectdbParams() libpq functions.

Can someone dig out the patch that Heikki had started to support psql
automatically setting the client encoding? I think that's what started
this whole API revision.