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