On Fri, Feb 19, 2010 at 12:07:42AM -0500, Tom Lane wrote:
Lew no...@lwsc.ehost-services.com writes:
Eric B. Ridge wrote:
That explains it. Thanks. Breaks the rule of least surprise,
but it is SQL.
SQL:1999 and later use a slightly different definition which is not
entirely upward
David Fetter da...@fetter.org writes:
On Fri, Feb 19, 2010 at 12:07:42AM -0500, Tom Lane wrote:
SQL:1999 and later use a slightly different definition which is not
entirely upward compatible with SQL-92. In most cases, however,
PostgreSQL will interpret an ORDER BY or GROUP BY expression the
Maybe I'm getting too old to SQL anymore, but I ran across something yesterday
in a machine generated query that took me over an hour to figure out.
Here's a little testcase. Maybe somebody can explain why the last Not
Expected case does what it does.
select version();
PostgreSQL 8.4.1 on
Eric B. Ridge wrote:
Maybe I'm getting too old to SQL anymore, but I ran across something yesterday in a machine generated query that took me over an hour to figure out.
Here's a little testcase. Maybe somebody can explain why the last Not
Expected case does what it does.
select version();
On Feb 18, 2010, at 4:31 PM, Scott Bailey wrote:
I'm not sure why you would be surprised by that behavior. You are grouping by
a timestamp, so any microsecond difference will be a new group.
I get that. ;) Hence the ::date. This is what doesn't make sense:
Expected: select day::date as
Eric B. Ridge wrote:
On Feb 18, 2010, at 4:31 PM, Scott Bailey wrote:
I'm not sure why you would be surprised by that behavior. You are grouping by a
timestamp, so any microsecond difference will be a new group.
I get that. ;) Hence the ::date. This is what doesn't make sense:
Expected:
On Feb 18, 2010, at 5:52 PM, Scott Bailey wrote:
SQL name resolution rules are that column names have higher precedence than
aliases and variables. So it will always bind to the column not the alias.
That explains it. Thanks. Breaks the rule of least surprise, but it is SQL.
eric
--
Sent
Scott Bailey wrote:
SQL name resolution rules are that column names
have higher precedence than aliases and variables.
So it will always bind to the column not the alias.
Eric B. Ridge wrote:
That explains it. Thanks. Breaks the rule of least surprise, but it is SQL.
I don't think it
Lew no...@lwsc.ehost-services.com writes:
Eric B. Ridge wrote:
That explains it. Thanks. Breaks the rule of least surprise, but it is SQL.
I don't think it does break the rule of least surprise. How would one
expect the column or the alias to have precedence without knowledge of
the rule
