Re: Patch: libpq new connect function (PQconnectParams) - Mailing list pgsql-hackers

From Guillaume Lelarge
Subject Re: Patch: libpq new connect function (PQconnectParams)
Date
Msg-id 4B5E2779.90708@lelarge.info
Whole thread Raw
In response to Re: Patch: libpq new connect function (PQconnectParams)  (Joe Conway <mail@joeconway.com>)
Responses Re: Patch: libpq new connect function (PQconnectParams)  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
Le 26/01/2010 00:04, Joe Conway a écrit :
> I'm reviewing the patch posted here:
>   http://archives.postgresql.org/pgsql-hackers/2010-01/msg01579.php
> for this commitfest item:
>   https://commitfest.postgresql.org/action/patch_view?id=259
> 

First, thanks for reviewing my patch.

> Patch attached - a few minor changes:
> -------------------------------------
> 1) Updated to apply cleanly against cvs tip

Sorry about this. I already updated it twice. I didn't think a new
update was needed.

> 2) Improved comments

Sure.

> 3) Moved much of what was in PQconnectStartParams() to a new
>    conninfo_array_parse() to be more consistent with existing code

You're right. It also makes the code more readable and understandable. I
should have done that.

> Questions/comments:
> -------------------
> a) Do we want an analog to PQconninfoParse(), e.g.
>    PQconninfoParseParams()? If not, it isn't worth keeping use_defaults
>    as an argument to conninfo_array_parse().

No, I don't think so. I can't find a use case for it.

> b) I refrained from further consolidation even though there is room.
>    For example, I considered leaving only the real parsing code in
>    conninfo_parse(), and having it return keywords and values arrays.
>    If we did that, the rest of the code could be modified to accept
>    keywords and values instead of conninfo, and therefore shared. I was
>    concerned about the probably small performance hit to the existing
>    code path. Thoughts?
> c) Obviously I liked the "two-arrays approach" better -- any objections
>    to that?

No objection. I prefer the other one, but it's just not that important.

I didn't put any documentation before knowing which one will be choosen.
So we still need to work on the manual.

Thanks again.


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


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: Patch: libpq new connect function (PQconnectParams)
Next
From: KaiGai Kohei
Date:
Subject: Re: RADIUS authentication