From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dmitriy Igrishin <dmitigr(at)gmail(dot)com>, pgsql-docs <pgsql-docs(at)postgresql(dot)org> |
Subject: | Re: PQconninfoParse() |
Date: | 2012-03-23 02:12:00 |
Message-ID: | CA+TgmoYUPXLsCwo3yyfezALDQKgzC6RH84xDA2KwDyYAy8fbTQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Tue, Oct 18, 2011 at 8:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sat, Oct 15, 2011 at 11:24 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Uh, is that actually a true statement? I thought the result *did*
>>> include default values. That's more or less the point of returning them
>>> all, after all.
>
>> Well, then I'm confused, because you and Dmitriy seem to be saying
>> opposite things.
>
> [ after experimenting with the code ... ] Oh, I had been thinking that
> PQconndefaults gives the same result as PQconninfoParse with an
> empty-string argument, but that's not the case. Indeed, the former
> fills in default values as current values, but the latter does not.
>
> The proposed wording change seems reasonable, except that "have a
> corresponding value" seems a bit vague. Maybe better "have a non-null
> val field".
I've committed something along these lines.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-03-23 02:12:30 | Re: [COMMITTERS] pgsql: Update docs on numeric storage requirements. |
Previous Message | Fujii Masao | 2012-03-23 01:21:59 | Re: [COMMITTERS] pgsql: Update docs on numeric storage requirements. |