Re: Postgres 8.3.5 - ECPG and the use of descriptors and cursors in multi-threaded programs

Hello Bosco,

Thank you for your comment. Yes, it would be nice to get some more comments on the allocate/deallocate on a connection issue.

I have verified that in my case deallocating a prepared statement, it guesses the wrong connection and returns an error. (The right one is doing auto-deallocation at disconnect time, though).

However, I just noticed that allocating a descriptor with the "AT <connection>" clause,
EXEC SQL AT :_thisDbConn ALLOCATE DESCRIPTOR :descname;
generates an ECPGallocate_desc() call without any connection name and that this can "screw up" the ECPGget_desc() function when guessing a connection. I could of course use:
EXEC SQL SET CONNECTION <connection name>;
before the allocate, but that would need mutex's all over to make sure that other threads will not set the connection too.

Any idea why the ecpg pre-compiler doesn't use the named connection for the ALLOCATE DESCRIPTOR statement even though it allows it ?

Please help,

Leif

----- "Bosco Rama" <postgres(at)boscorama(dot)com> wrote:

> Leif Jensen wrote:
> >
> > Is it really not possible to use 2 separate connection within 1
> thread
> > at the same time ? or is it an error in the ecpg library ?
>
> It should be entirely possible to run multiple connections in a
> single
> thread as long as you manage the 'AT connName' clauses properly.
>
> Though, IIRC, using an 'AT connName' clause on any sort of
> 'deallocate'
> statement generates an error in ecpg:
>
> ecpg -o test.c test.pgc
> test.pgc:35: ERROR: AT option not allowed in DEALLOCATE statement
>
> This happens when trying to deallocate a query or a prepared
> statement.
> I don't use descriptors but the error message indicates it's _any_
> sort
> of deallocate.
>
> So, it would appear that you can allocate on a connection but not
> deallocate from one. :-(
>
> I'm wonder if Tom or Michael can shine some light on this one?
>
> Bosco.