Hi All,



If I have a query which has both 'group by' and 'order by' clauses AND
the ordering is on a column which is NOT part of the grouping it appears
to stop the 'grouping by' completely silently.



Eg.

select g.pid

from gobz g

group by g.pid

order by g.tsig



If you drop the order by clause or change it to use a column in the
grouping then it will function as you'd expect.



I have castigated the programmer!



But whats the consensus out there...Is this a bug or should he have
gotten an error from the system or is this expected behaviour?



I can't find anything in the SQL guide which would say
explicitly...don't do this.



But by way of comparison, if you do...

select g.pid, count(*)

from gobz g

group by g.pid

order by g.tsig

Executing . . .



E_US0871 Sort column 'tsig' not found in target list.

(Fri Jul 24 15:18:41 2009)



Marty Bowes

Given the following table, what output do you expect? :

pid tsig
--- ----
1 a
1 b
2 a
2 b

Actually I'd expect Ingres to issue a syntax error.

Ronald


--
rjeninga

On Jul 24, 2009, at 10:23 AM, Martin Bowes wrote:

I'd expect either "sort column not in target list", or "the columns
in the select clause must be contained in the group by clause".

Dropping the group-by silently is a bug IMO.

Karl

Martin Bowes wrote:

Well apart from expecting you to whack the programmer, I'd expect
an error message.

ORDER BY can imply additional columns to include in the target list,
which are used for sorting and are then projected away before delivering
the results. But implied columns not mentioned in the GROUP BY should
provoke the usual error message you get any time you have columns in
the target list that are not included in the GROUP BY clause.

Another way to look at it is that ORDER BY can't imply
including additional columns after grouping because by then they don't
exist to be included, so you should still get an error.

--
Roy

UK Ingres User Association Conference 2010 will be on Tuesday June 8 2010
Go to http://www.iua.org.uk/join to get on the mailing list.

Here is how a SELECT works in SQL ... at least in theory. Real
products will optimize things, but the code has to produce the same
results.

a) Start in the FROM clause and build a working table from all of the
joins, unions, intersections, and whatever other table constructors
are there. The <table expression> AS <correlation name> option allows
you give a name to this working table which you then have to use for
the rest of the containing query.

b) Go to the WHERE clause and remove rows that do not pass criteria;
that is, that do not test to TRUE (i.e. reject UNKNOWN and FALSE).
The WHERE clause is applied to the working set in the FROM clause.

c) Go to the optional GROUP BY clause, partiton the original table
into groups and reduce each grouping to a *single* row, replacing the
original working table with the new grouped table. The rows of a
grouped table must be only group characteristics: (1) a grouping
column (2) a statistic about the group (i.e. aggregate functions) (3)
a function or constant(4) an expression made up of only those three
items. The original table no longer exists and you cannot reference
anything in it (this was an error in early Sybase products).

d) Go to the optional HAVING clause and apply it against the grouped
working table; if there was no GROUP BY clause, treat the entire table
as one group.

e) Go to the SELECT clause and construct the expressions in the list.
This means that the scalar subqueries, function calls and expressions
in the SELECT are done after all the other clauses are done. The AS
operator can also give names to expressions in the SELECT list. These
new names come into existence all at once, but after the WHERE clause,
GROUP BY clause and HAVING clause have been executed; you cannot use
them in the SELECT list or the WHERE clause for that reason.

If there is a SELECT DISTINCT, then redundant duplicate rows are
removed. For purposes of defining a duplicate row, NULLs are treated
as matching (just like in the GROUP BY).

f) Nested query expressions follow the usual scoping rules you would
expect from a block structured language like C, Pascal, Algol, etc.
Namely, the innermost queries can reference columns and tables in the
queries in which they are contained.

g) The ORDER BY clause is part of a cursor, not a query. The result
set is passed to the cursor, which can only see the names in the
SELECT clause list, and the sorting is done there. The ORDER BY
clause cannot have expression in it, or references to other columns
because the result set has been converted into a sequential file
structure and that is what is being sorted.

As you can see, things happen "all at once" in SQL, not "from left to
right" as they would in a sequential file/procedural language model.
In those languages, these two statements produce different results:
READ (a, b, c) FROM File_X;
READ (c, a, b) FROM File_X;

while these two statements return the same data:

SELECT a, b, c FROM Table_X;
SELECT c, a, b FROM Table_X;

Think about what a confused mess this statement is in the SQL model.

SELECT f(c2) AS c1, f(c1) AS c2 FROM Foobar;

That is why such nonsense is illegal syntax.

Hi Ronald,

Using your data...
select g.pid
from gobz g
group by g.pid
order by g.tsig
;

+-------------+
(4 rows)

select g.pid
from gobz g
group by g.pid

+-------------+
(2 rows)

Marty

-----Original Message-----
From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of
Ingres Forums
Sent: 24 July 2009 15:58
To: info-ingres (AT) kettleriverconsulting (DOT) com
Subject: Re: [Info-Ingres] mixing 'group by' and 'order by' clauses


Given the following table, what output do you expect? :

pid tsig
--- ----
1 a
1 b
2 a
2 b

Actually I'd expect Ingres to issue a syntax error.

Ronald


--
rjeninga
------------------------------------------------------------------------
rjeninga's Profile:
http://community.ingres.com/forum/member.php?userid=679
View this thread:
http://community.ingres.com/forum/sh...ad.php?t=10958

_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://www.kettleriverconsulting.com...fo/info-ingres

I've raised it as a level 4 bug.

Marty

-----Original Message-----
From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of Karl
& Betty Schendel
Sent: 24 July 2009 16:09
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] mixing 'group by' and 'order by' clauses


On Jul 24, 2009, at 10:23 AM, Martin Bowes wrote:

I'd expect either "sort column not in target list", or "the columns
in the select clause must be contained in the group by clause".

Dropping the group-by silently is a bug IMO.

Karl


_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://www.kettleriverconsulting.com...fo/info-ingres

Hi Marty,

if you posted ingres output, you found a bug in ingres.

The original statement doesn't make sense, as Roy and Celko already
pointed out. My small example was intended to show this (and that's why
I asked for the _expected_ result, not the result ingres produces).

I already saw your message that you reported this behaviour as a bug.

Regards,

Ronald


--
rjeninga

I will be out of the office now until Monday 17th August, and will
respond to your e-mail as soon as I can upon my return.

If the matter is urgent, please raise a call via the ICT Helpdesk.


This e-mail and any files transmitted with it are the property of the
London Borough of Havering, are confidential, may be subject to legal privilege
and are intended only for the person(s) or organisation(s) named above.
Any unauthorised use, retention, distribution, copying or disclosure
is strictly prohibited. If you receive this email in error, please notify
the sender immediately and delete this e-mail from your system.
WARNING: It is your responsibility to take all necessary steps to
ensure this e-mail and any attachments to it are free from viruses.

Ingres Forums wrote:

How can there be an "expected" result for invalid SQL?