Could OSDB Replace the SQL Standard Committe?

Lukas’ recent post on [http://pooteeweet.org/blog/1201 solving the prepared statement problem] got wondering, if open source databases implement something, how likely is it to become a defacto standard? The best example of this is the LIMIT clause, which both [http://dev.mysql.com/doc/refman/5.0/en/limit-optimization.html MySQL] and [http://www.postgresql.org/docs/current/interactive/queries-limit.html PostgreSQL] support, and that anyone who has used either database will tell you is a far superior tool to what it is available in other systems (don’t get me wrong, [http://www.oracle.com/technology/oramag/oracle/06-sep/o56asktom.html rownum()] has it’s place, but for what LIMIT does it’s not as good). And while LIMIT is not standard SQL, can you imagine if the SQL Standard Committee were to adopt a syntax that conflicted with the Postgres/MySQL implementations? Take this with a grain of salt, but really there are only 5 databases that matter anymore, Oracle, DB2, MS SQL, MySQL, and Postgres. Sure, there are many other successful database systems, and also some niche databases that are big players in their segment, but those 5 are the ones that set the tone. Even with Oracle far out pacing MySQL on dollars, the number of people who have joined the tech industry within the last 5 years who have hands on experience with MySQL high enough that it is not uncommon for people to look for their syntax in other database products (for better or worse). And remember, Postgres is [http://freshmeat.net/stats/#popularity even more popular] than MySQL in some places; one should expect the impact of open source databases to rise in this area faster than just by watching market share. So, what kind of problems could be solved with new syntax? Honestly I am not really sure. One piece of syntax I always though SQL got wrong was the UPDATE statement. I’ve always thought that the syntax should have been UPDATE table WHERE conditions SET column=data, if only because it would have saved us from countless unconstrained updates from junior DBA’s. Other examples might be to take something like MySQL’s [http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html ON DUPLICATE KEY] syntax, clear up any sanity issues with implementation, and then implement it in Postgres. (Yes, this examples are questionable, since there are SQL Standard ways of doing this stuff, but the syntax of this command sure seems more user friendly). Of course, this whole idea overlooks the notion that the SQL Standard committee has often been used as a tool between database vendors to make life tougher for their competitors, so it might be unlikely that the committee would ever adopt the syntax from the [http://planetosdb.org/ FLOSS community] if it meant giving them some type of advantage, but this is also why FLOSS databases could give hope, since as more user oriented projects, if they worked together you should really see syntax that makes everyones lives easier. Imagine Postgres, MySQL, Firebird, SQLite, and Ingres all working together to create their own, user driven syntaxes.