Re: Thread-unsafe coding in ecpg

I wrote:
> This suggests that, rather than throwing up our hands if the initial
> _configthreadlocale call returns -1, we should act as though the function
> doesn't exist, and just soldier on the same as before. The code in there
> assumes that -1 is a can't-happen case and doesn't try to recover,
> but apparently that's over-optimistic.

I pushed a patch to fix that.

It looks to me like the reason that the ecpg tests went into an infinite
loop is that compat_informix/test_informix.pgc has not considered the
possibility of repeated statement failures:

while (1)
{
$fetch forward c into :i, :j, :c;
if (sqlca.sqlcode == 100) break;
else if (sqlca.sqlcode != 0) printf ("Error: %ld\n", sqlca.sqlcode);

if (risnull(CDECIMALTYPE, (char *)&j))
printf("%d NULL\n", i);
else
{
int a;

dectoint(&j, &a);
printf("%d %d \"%s\"\n", i, a, c);
}
}

I know zip about ecpg coding practices, but wouldn't it be a better idea
to break out of the loop on seeing an error?

regards, tom lane