Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154]) by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f1L0x2x94843; Tue, 20 Feb 2001 19:59:02 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f1L0ww908769; Tue, 20 Feb 2001 19:58:58 -0500 (EST) To: "Postgres El Mejor" cc: pgsql-interfaces@postgresql.org, Michael Meskes Subject: Re: FOR UPDATE is not allowed in this context In-reply-to: References: Comments: In-reply-to "Postgres El Mejor" message dated "Tue, 20 Feb 2001 19:16:46 -0500" Date: Tue, 20 Feb 2001 19:58:58 -0500 Message-ID: <8766.982717138@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200102/135 X-Sequence-Number: 1092 "Postgres El Mejor" writes: > Greetings: > When precompiling the following sentence the precompiler shows the message > "FOR UPDATE is not allowed in this context". > EXEC SQL SELECT camp_1 INTO :n1 WHERE llave = :var_llave FOR UPDATE; This seems to me to be a bug in ecpg: the variable ForUpdateNotAllowed doesn't get reset between statements. If you experiment more you'll probably find the behavior depends on the preceding statements. That bug is gone in 7.1 by virtue of the fact that the variable doesn't exist anymore ... but I think there are related bugs associated with some other ad-hoc flags in the ecpg parser, none of which get reset at what I would consider a reasonable place to reset them ... regards, tom lane