Thread: FOR UPDATE is not allowed in this context
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; It seems to be a problem with the host variables because it precompiles well the following sentence: EXEC SQL SELECT camp_1 INTO :n1 WHERE llave = 'abcd' FOR UPDATE; Thanks in advance for your help, ------------------------------------------------------------------------- Jhon Orellana Quito - Ecuador South America _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
"Postgres El Mejor" <postgres99@hotmail.com> 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
On Tue, Feb 20, 2001 at 07:58:58PM -0500, Tom Lane wrote: > 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 It should have been resetted at the beginning of a statement. But then it does not exist anymore in the actual release. > 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 ... Which one do you think of? I agree that some of this stuff is just a hack I needed to get that check into the parser. But so far I have yet to see a bug reported on these. Except for the one we are talking about of course. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
<div><p>Greetings:<p>I upgrade my RedHat 6.2 to RedHat 7.0 and with it my Postgresql 6.5 to Postgresql 7.02. When I triedto start my new Postgresql with the command:<p> "/etc/rc.d/init.d/postgresql start"<p>I obtained the next message:<p>"oldversion. Need to Upgrade."<p>Could anybody tell me: What do I need to do? How can I start my new release?<p>Thanksin advance.<p>-----------------------------<p>Jhon Orellana<p>Quito-Ecuador<p><a href="mailto:postgres99@hotmail.com">postgres99@hotmail.com</a><p>------------------------------<br/></div><br clear="all"/><hr />Get Your Private, Free E-mail from MSN Hotmail at <a href="http://www.hotmail.com">http://www.hotmail.com</a>.<br/>
Michael Meskes <meskes@postgresql.org> writes:
> On Tue, Feb 20, 2001 at 07:58:58PM -0500, Tom Lane wrote:
>> ... 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 ...
> Which one do you think of? I agree that some of this stuff is just a hack I
> needed to get that check into the parser. But so far I have yet to see a bug
> reported on these. Except for the one we are talking about of course.
Well, for example, once a CREATE RULE has been seen, ecpg will accept
'old' and 'new' in all subsequent statements, because QueryIsRule is
never reset. FoundInto is reset, but in the wrong place, meaning that
"CREATE TABLE/AS SELECT may not specify INTO" might be triggered
inappropriately, or not triggered when it's supposed to be.
My advice would be to eliminate both variables and leave it to the
backend to make the corresponding error checks.
BTW, I just committed some ecpg changes to modify the way
case-conversion of keywords is done, to keep it in line with the
backend. You'd said you wanted notification of such things ...
regards, tom lane
On Wed, Feb 21, 2001 at 02:03:00PM -0500, Tom Lane wrote: > Well, for example, once a CREATE RULE has been seen, ecpg will accept > 'old' and 'new' in all subsequent statements, because QueryIsRule is Ouch! This is of course a bug I should have found. > never reset. FoundInto is reset, but in the wrong place, meaning that > "CREATE TABLE/AS SELECT may not specify INTO" might be triggered > inappropriately, or not triggered when it's supposed to be. Yes, I did not correct this with the last changes to SelectStmt rules. > My advice would be to eliminate both variables and leave it to the > backend to make the corresponding error checks. Yes, that's one possibility. I do though prefer to do syntax checks at compile time rather than at run time. > BTW, I just committed some ecpg changes to modify the way > case-conversion of keywords is done, to keep it in line with the Thanks. > backend. You'd said you wanted notification of such things ... It's not a must. It just helps me track down what's going on. In the past I did remove some changes due to not noticing something had changed in CVS. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!