Re: [GENERAL] Count(*) throws error

From: Richard Huxton <dev(at)archonet(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] Count(*) throws error
Date: 2007-07-12 18:11:33
Message-ID: 46966ED5.4080204@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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 solution is to have some clear syntactic sugar denoting
where variables are to be interpolated:
SELECT * FROM foo WHERE (bar + 1) = bar -- Which is the var?
SELECT * FROM foo WHERE (bar + 1) = $bar -- OK
SELECT * FROM foo WHERE (bar + 1) = {bar} -- OK
It's not clear to plpgsql because it's *not clear*.

In any other namespace-conflict situation I can think of it's always
inner-definition-is-visible. This would of course solve the problem, but
only by preventing you from substituting in variables that conflict
with columns. Unless you generate a warning at function compile-time
that doesn't seem much better.

--
Richard Huxton
Archonet Ltd

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Benjamin Arai 2007-07-12 18:19:18 Re: Big table with UNION ALL or partitioning with Tsearch2
Previous Message Oleg Bartunov 2007-07-12 18:07:49 Re: Big table with UNION ALL or partitioning with Tsearch2

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2007-07-12 18:13:23 Re: compiler warnings on the buildfarm
Previous Message Michael Paesold 2007-07-12 18:02:55 Re: 2PC-induced lockup