pgsql-sql is probably the appropriate list for future queries of this 

Note that the below is my personal opinion; each PG developer has their 

> 1. Just a minor annoyance, but why must subqueries in FROM clauses
> have an alias?  For instance suppose that I have an orders table, and
> one of the fields is userid.  The following is unambiguous and is
> legal in Oracle:

I *think* the alias is a requirement of the SQL standard.  Yes/No?

> 2. Why is 'non-integer constant in GROUP BY' an error?

Again, this needs to reference one of the SQL standards if you're 
interested in a change of behavior.  If we're out of standards compliance, 
that's a strong argument.  If we're in compliance, you have a pretty steep 
hurdle to justify new syntax.

> 3. How hard would it be to have postgres ignore aliases in group by
> clauses? 

Unfortunately, I think this is also a SQL compliance issue.  However, I'd 
be more liable to support your arguments for it; it's much more obviously 
useful functionality.

> 4) Items 2 and 3 would both be made irrelevant if postgres did
> something that I'd really, really would like.  Which is to assume that
> a query without a group by clause, but with an aggregate function in
> the select, should have an implicit group by clause where you group by
> all non-aggregate functions in the select.

In addition to SQL compliance issues, we're reluctant to do anything which 
makes implicit assumptions which could easily be wrong in PostgreSQL.  
Such shortcutting all to often leads to runaway queries or wrong data when 
the assumptions are incorrect.  MySQL gives us lots of examples of what 
can happen if you do too many things for convenience and compromise 


Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to