On Mon, Nov 15, 2010 at 11:13, Robert Haas wrote:
>> I added an additional cleanup to 'header_mode' in ecpg; I changed the type
>> from bool to char to hold 'h' or 'c'. Do you think it is reasonable?
>
> I looked at this but found that part a bit too clever for its own good.
>
> So committed the r
On Wed, Nov 3, 2010 at 9:45 PM, Itagaki Takahiro
wrote:
> On Wed, Nov 3, 2010 at 2:19 AM, Michael Meskes wrote:
>> On Mon, Nov 01, 2010 at 12:17:02PM +0900, Itagaki Takahiro wrote:
>>> There are some "== true" in the codes, but they might not be safe
>>> because all non-zero values are true in C.
On Wed, Nov 3, 2010 at 6:45 PM, Itagaki Takahiro
wrote:
> On Wed, Nov 3, 2010 at 2:19 AM, Michael Meskes wrote:
>> On Mon, Nov 01, 2010 at 12:17:02PM +0900, Itagaki Takahiro wrote:
>>> There are some "== true" in the codes, but they might not be safe
>>> because all non-zero values are true in C.
On Wed, Nov 3, 2010 at 2:19 AM, Michael Meskes wrote:
> On Mon, Nov 01, 2010 at 12:17:02PM +0900, Itagaki Takahiro wrote:
>> There are some "== true" in the codes, but they might not be safe
>> because all non-zero values are true in C. Is it worth cleaning up them?
Here is a proposed cleanup tha
On Mon, Nov 01, 2010 at 12:17:02PM +0900, Itagaki Takahiro wrote:
> There are some "== true" in the codes, but they might not be safe
> because all non-zero values are true in C. Is it worth cleaning up them?
> ...
> src/interfaces/ecpg/ecpglib/connect.c(168): if (con->autocommit ==
> true && str