delta/postgresql.git/src/test/regress/expected/select_having_2.out, branch master git.postgresql.org: git/postgresql.git Add a bunch of new error location reports to parse-analysis error messages. 2008-09-01T20:42:46+00:00 Tom Lane tgl@sss.pgh.pa.us 2008-09-01T20:42:46+00:00 b153c0920960a6059b67969469166fb29c0105d7 There are still some weak spots around JOIN USING and relation alias lists, but most errors reported within backend/parser/ now have locations. 
There are still some weak spots around JOIN USING and relation alias lists,
but most errors reported within backend/parser/ now have locations.
Make the behavior of HAVING without GROUP BY conform to the SQL spec. 2005-03-10T23:21:26+00:00 Tom Lane tgl@sss.pgh.pa.us 2005-03-10T23:21:26+00:00 595ed2a8550e34c0abe64569a104d92ad077ec08 Formerly, if such a clause contained no aggregate functions we mistakenly treated it as equivalent to WHERE. Per spec it must cause the query to be treated as a grouped query of a single group, the same as appearance of aggregate functions would do. Also, the HAVING filter must execute after aggregate function computation even if it itself contains no aggregate functions. 
Formerly, if such a clause contained no aggregate functions we mistakenly
treated it as equivalent to WHERE.  Per spec it must cause the query to
be treated as a grouped query of a single group, the same as appearance
of aggregate functions would do.  Also, the HAVING filter must execute
after aggregate function computation even if it itself contains no
aggregate functions.
It seems some case-insensitive locales sort upper case before lower 2003-07-18T03:21:53+00:00 Tom Lane tgl@sss.pgh.pa.us 2003-07-18T03:21:53+00:00 5ea214b590f626154d11a28214ca7c774d9f8cb3 (BBBB before bbbb) and others the other way around. Provide comparison files that cater to both approaches. 
(BBBB before bbbb) and others the other way around.  Provide comparison
files that cater to both approaches.