On Fri, 11 Mar 2005 10:37:13 +1300, Mark Kirkwood
<[EMAIL PROTECTED]> wrote:
>Firebird 1.5.1 FreeBSD 5.3
>[correct results]
Interbase 6.0:
SQL> create table tab (col integer);
SQL> select 1 from tab having 1=0;
SQL> select 1 from tab having 1=1;
0<---:-)
> 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
Informix:
select tabname from systables having 2 > 1;
294: The column (tabname) must be in the GROUP BY list.
Tom Lane wrote:
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-c
On Oracle 9.2 you get 0, 0, 0, and 2 rows.
--Barry
SQL> create table tab (col integer);
Table created.
SQL> select 1 from tab having 1=0;
no rows selected
SQL> select 1 from tab having 1=1;
no rows selected
SQL> insert into tab values (1);
1 row created.
SQL> insert into tab values (2);
On Thu, Mar 10, 2005 at 12:44:50PM -0500, Tom Lane wrote:
> Would those of you with access to other DBMSes try this:
DB2/LINUX 8.1.6
> create table tab (col integer);
> select 1 from tab having 1=0;
1
---
0 record(s) selected.
> select 1 from tab having 1=1;
1
-
Tom Lane wrote:
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-c
On Thu, 10 Mar 2005, Tom Lane wrote:
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;
"Barry Lind" <[EMAIL PROTECTED]> writes:
> On Oracle 9.2 you get 0, 0, 0, and 2 rows.
Really!? Well, we always knew they were a bit standards-challenged ;-).
I have more faith in DB2 being an accurate implementation of the spec.
regards, tom lane
On Thu, Mar 10, 2005 at 12:44:50PM -0500, Tom Lane wrote:
>
> 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
Tom Lane wrote:
>
> 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;
Tom Lane wrote:
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-c
, 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
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,
>
13 matches
Mail list logo
