Date: Thu, 22 Feb 2001 13:55:10 +0100
From: Michael Meskes <meskes@postgresql.org>
To: pgsql-interfaces@postgresql.org
Subject: Re: FOR UPDATE is not allowed in this context
Message-ID: <20010222135510.A13034@feivel.credativ.de>
Mail-Followup-To: pgsql-interfaces@postgresql.org
References: <F76sa7qEqlehFvHkQFY00003779@hotmail.com>
	<8766.982717138@sss.pgh.pa.us>
	<20010221140221.A28917@feivel.credativ.de>
	<11485.982782180@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <11485.982782180@sss.pgh.pa.us>;
	from tgl@sss.pgh.pa.us on Wed, Feb 21, 2001 at 02:03:00PM -0500

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!