On Thu, Feb 7, 2013 at 1:15 AM, Phil Sorber <phil@omniti.com> wrote:
> On Wed, Feb 6, 2013 at 11:11 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Thu, Feb 7, 2013 at 12:05 AM, Phil Sorber <phil@omniti.com> wrote:
>>> On Tue, Feb 5, 2013 at 12:44 PM, Phil Sorber <phil@omniti.com> wrote:
>>>> On Tue, Feb 5, 2013 at 9:08 AM, Phil Sorber <phil@omniti.com> wrote:
>>>>> On Tue, Feb 5, 2013 at 9:06 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>>>>>> Phil Sorber escribió:
>>>>>>> On Tue, Feb 5, 2013 at 6:41 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>>>>>> > On Sat, Feb 2, 2013 at 9:55 PM, Phil Sorber <phil@omniti.com> wrote:
>>>>>>> >> OK, here is the patch that handles the connection string in dbname.
>>>>>>> >> I'll post the other patch under a different posting because I am sure
>>>>>>> >> it will get plenty of debate on it's own.
>>>>>>> >
>>>>>>> > I'm sorry, can you remind me what this does for us vs. the existing coding?
>>>>>>> >
>>>>>>>
>>>>>>> It's supposed to handle the connection string passed as dbname case to
>>>>>>> be able to get the right output for host:port.
>>>>>>
>>>>>> Surely the idea is that you can also give it a postgres:// URI, right?
>>>>>
>>>>> Absolutely.
>>>>
>>>> Here is it. I like this approach more than the previous one, but I'd
>>>> like some feedback.
>>
>> The patch looks complicated to me. I was thinking that we can address
>> the problem
>> just by using PQconninfoParse() and PQconndefaults() like uri-regress.c does.
>> The patch should be very simple. Why do we need so complicated code?
>
> Did you like the previous version better?
>
> http://www.postgresql.org/message-id/CADAkt-hnB3OhCpkR+PCg1c_Bjrsb7J__BPV+-jrjS5opjR2oww@mail.gmail.com
Yes because that version is simpler. But which version is better depends on
the reason why you implemented new version. If you have some idea about
the merit and demerit of each version, could you elaborate them?
+ set_connect_options(connect_options, &pgdbname, &pghost,
&pgport, &connect_timeout, &pguser);
This code prevents us from giving options other than the above, for example
application_name, in the conninfo. I think that pg_isready should accept all
the libpq options.
When more than one -d options are specified, psql always prefer the last one
and ignore the others. OTOH, pg_isready with this patch seems to merge them.
I'm not sure if there is specific rule about the priority order of -d
option. But
it seems better to follow the existing way, i.e., always prefer the
last -d option.
Regards,
--
Fujii Masao