Good morning Dr. Hipp, Thanks for the quick reply and the detailed explanation. I expected that that would be the answer, but it's good to hear it from the authority.
Changing directions just a bit: would this be the case for things like ROLLUP and CUBE as well, or might those be more easily achievable in the current architecture given that they happen after the aggregation specified by the GROUP BY clause, similar to the HAVING clause? Thanks -Tom > -----Original Message----- > From: D. Richard Hipp [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 23, 2005 9:13 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] COUNT(DISTINCT) > > On Wed, 2005-03-23 at 09:02 -0500, Thomas Briggs wrote: > > Bearing in mind that I'm aware of the published workaround for > > COUNT(DISTINCT x), and also that as of yet I know nothing of the > > internals of SQLite: what would be involved in extending SQLite to > > support the traditional "COUNT(DISTINCT x)" syntax? Is > this something > > that hasn't been done because the workaround has always > been sufficient, > > or something that would require a complete redesign to be feasible? > > > > This would require a major redesign. > > Functions are parsed as function-name "(" expression "," ... ")" > So the first rework would be to somehow allow the "DISTINCT" > keyword for > the > "COUNT" function while disallowing it elsewhere. > > Functions are implemented by calling a function at the appropriate > time. (See the sqlite3_create_function API.) Functions do not > fundamentally change the processing of a statement. The parser and > code generate doe not know anything about functions other than a > pointer to the C-procedure used to implement them. But to > implement COUNT(DISTINCT) all that would have to change. The > COUNT(DISTINCT) function would have to be handled separately. > The parser and code generator would have to generate completely > different VM code to implement an SQL statement depending on > whether or not a COUNT(DISTINCT) was present or not. > > The sqlite3_create_function API currently allows the user to > override any function. If COUNT(DISTINCT) where implemented, this > would have to change to make an exception for the COUNT() function, > presumably. Or else the parser/code generator would have to detect > that COUNT() had been overloaded and not do its special processing > for COUNT(DISTINCT) and in fact disallow COUNT(DISTINCT). > > These are just a few of the complications that spring to mind. > I'm sure I would think of others if I spent some time on the > subject. > -- > D. Richard Hipp <[EMAIL PROTECTED]> > >
