PS.: That goes for the AT clause on the GET DESCRIPTOR statement too. The connection name is not included in the ECPGget_desc() call. ----- "Leif Jensen" <leif@xxxxxxxxxxx> wrote: > 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@xxxxxxxxxxxxx> 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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general