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