Here is your Sql run in a DB2 database. connect to phoenix Database Connection Information
Database server = DB2/LINUX 8.1.5 SQL authorization ID = GILL Local database alias = PHOENIX create table tab (col integer) DB20000I The SQL command completed successfully. select 1 from tab having 1=0 1 ----------- 0 record(s) selected. select 1 from tab having 1=1 1 ----------- 1 1 record(s) selected. insert into tab values(1) DB20000I The SQL command completed successfully. insert into tab values(2) DB20000I The SQL command completed successfully. select 1 from tab having 1=0 1 ----------- 0 record(s) selected. select 1 from tab having 1=1 1 ----------- 1 1 record(s) selected. Hope that helps. -Jgill -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tom Lane Sent: Thursday, March 10, 2005 11:45 AM To: pgsql-hackers@postgresql.org; pgsql-bugs@postgresql.org Subject: Re: [BUGS] [HACKERS] We are not following the spec for HAVING without GROUP BY I wrote: > This is quite clear that the output of a HAVING clause is a "grouped > table" no matter whether the query uses GROUP BY or aggregates or not. > What that means is that neither the HAVING clause nor the targetlist > can use any ungrouped columns except within aggregate calls; that is, > select col from tab having 2>1 > is in fact illegal per SQL spec, because col isn't a grouping column > (there are no grouping columns in this query). Actually, it's even more than that: a query with HAVING and no GROUP BY should always return 1 row (if the HAVING succeeds) or 0 rows (if not). If there are no aggregates, the entire from/where clause can be thrown away, because it can have no impact on the result! Would those of you with access to other DBMSes try this: create table tab (col integer); select 1 from tab having 1=0; select 1 from tab having 1=1; insert into tab values(1); insert into tab values(2); select 1 from tab having 1=0; select 1 from tab having 1=1; I claim that a SQL-conformant database will return 0, 1, 0, and 1 rows from the 4 selects --- that is, the contents of tab make no difference at all. (MySQL returns 0, 0, 0, and 2 rows, so they are definitely copying our mistake...) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq