Re: [GENERAL] Count(*) throws error

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

Gregory Stark <stark(at)enterprisedb(dot)com> 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 keep around that parse tree instead of just the series of
> lex tokens to later call analyze on and execute.

Hmm. That sounds cool but I think it actually has a pretty substantial
disadvantage --- there is then no easily user-readable representation of
the query that shows *which* occurrences got substituted. With the
textual replacement method you have a string you can look at, though
it's true that we don't always show it to the user if we are not aware
there's a problem.

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).

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Benjamin Arai 2007-07-12 16:38:26 Big table with UNION ALL or partitioning with Tsearch2
Previous Message Aurynn Shaw 2007-07-12 15:51:05 Re: Mac OS X

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2007-07-12 16:15:54 Re: compiler warnings on the buildfarm
Previous Message Peter Eisentraut 2007-07-12 15:44:22 Re: compiler warnings on the buildfarm