Ben, pgsql-sql is probably the appropriate list for future queries of this nature.
Note that the below is my personal opinion; each PG developer has their own. > 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 correctness. -- --Josh 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