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

Re: Patch: libpq new connect function (PQconnectParams)

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: libpq new connect function (PQconnectParams)
Date: 2010-01-25 23:21:29
Message-ID: 4B5E2779.90708@lelarge.info (view raw or flat)
Thread:
Lists: 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.org
 http://dalibo.com

In response to

Responses

pgsql-hackers by date

Next:From: KaiGai KoheiDate: 2010-01-25 23:52:00
Subject: Re: RADIUS authentication
Previous:From: Joe ConwayDate: 2010-01-25 23:04:43
Subject: Re: Patch: libpq new connect function (PQconnectParams)

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