Re: Patch: libpq new connect function (PQconnectParams)
От | Guillaume Lelarge |
---|---|
Тема | Re: Patch: libpq new connect function (PQconnectParams) |
Дата | |
Msg-id | 4B5E2779.90708@lelarge.info обсуждение исходный текст |
Ответ на | Re: Patch: libpq new connect function (PQconnectParams) (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: Patch: libpq new connect function (PQconnectParams)
|
Список | 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 по дате отправления: