Re: [HACKERS] [GENERAL] Count(*) throws error

2007-07-12 Thread Richard Huxton
Tom Lane wrote: Again, I'm trying to look at the big picture of both syntactic and semantic errors. If we solve only the syntactic end of it I think we'd actually be worse off, because then users would be even more lost when they hit a semantic error (unwanted substitution). The only real solu

Re: [HACKERS] [GENERAL] Count(*) throws error

2007-07-12 Thread Tom Lane
Gregory Stark <[EMAIL PROTECTED]> writes: > So instead of substituting them as the tokens are lexed, instead suck in the > tokens, run the parser -- which we currently do anyways just to check the > syntax -- then walk the tree looking for ColumnRefs where the name matches a > variable name. Then k

Re: [HACKERS] [GENERAL] Count(*) throws error

2007-07-12 Thread Gregory Stark
"Tom Lane" <[EMAIL PROTECTED]> writes: > "Simon Riggs" <[EMAIL PROTECTED]> writes: >> On Wed, 2007-07-11 at 18:13 -0400, Tom Lane wrote: >>> "Simon Riggs" <[EMAIL PROTECTED]> writes: Seems like we could be slightly more friendly without too much bother: at least only substitute after the

Re: [HACKERS] [GENERAL] Count(*) throws error

2007-07-12 Thread Tom Lane
Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> Actually, rather than get into that sort of AI-complete project, > Is it really AI-complete? ISTM the *only* place where a parameter is allowed > is where the parser inserts a ColumnRef node? The first problem

Re: [HACKERS] [GENERAL] Count(*) throws error

2007-07-12 Thread Tom Lane
"Simon Riggs" <[EMAIL PROTECTED]> writes: > On Wed, 2007-07-11 at 18:13 -0400, Tom Lane wrote: >> "Simon Riggs" <[EMAIL PROTECTED]> writes: >>> Seems like we could be slightly more friendly without too much bother: >>> at least only substitute after the VALUES clause in INSERT. >> >> Surely you je

Re: [HACKERS] [GENERAL] Count(*) throws error

2007-07-12 Thread Gregory Stark
"Tom Lane" <[EMAIL PROTECTED]> writes: > "Simon Riggs" <[EMAIL PROTECTED]> writes: >> Seems like we could be slightly more friendly without too much bother: > > Actually, rather than get into that sort of AI-complete project, Is it really AI-complete? ISTM the *only* place where a parameter is al

Re: [HACKERS] [GENERAL] Count(*) throws error

2007-07-12 Thread Simon Riggs
On Wed, 2007-07-11 at 18:13 -0400, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > Seems like we could be slightly more friendly without too much bother: > > at least only substitute after the VALUES clause in INSERT. > > Surely you jest. No. There are a places where parameters cl

Re: [HACKERS] [GENERAL] Count(*) throws error

2007-07-11 Thread Tom Lane
"Simon Riggs" <[EMAIL PROTECTED]> writes: > Seems like we could be slightly more friendly without too much bother: Actually, rather than get into that sort of AI-complete project, it strikes me that the most useful response is user education. There ought to be a section in the plpgsql documentati

Re: [HACKERS] [GENERAL] Count(*) throws error

2007-07-11 Thread Tom Lane
"Simon Riggs" <[EMAIL PROTECTED]> writes: > Seems like we could be slightly more friendly without too much bother: > at least only substitute after the VALUES clause in INSERT. Surely you jest. regards, tom lane ---(end of broadcast)---

Re: [HACKERS] [GENERAL] Count(*) throws error

2007-07-11 Thread Simon Riggs
On Wed, 2007-07-11 at 17:42 -0400, Tom Lane wrote: > "Jasbinder Singh Bali" <[EMAIL PROTECTED]> writes: > > I'm using the following statement in my plpgsql function > > > SELECT INTO no_rows COUNT(*) FROM tbl_concurrent; > > > I have decalred no_rows int4 and initialized it to zero > > > Running