PostgreSQL and the SQL standards process

For what it's worth, I've seen strong interest in following the standards on the Pg lists - even in cases where the standards are of dubious sense or downright stupid. That applies both for formal ISO standard features and where compatibility with major-vendor language extensions like to_char is in question. The documentation reflects that, with clear coverage of which Pg features are part of the standard and which are extensions.

There's certainly a lot of frustration with the standard process's exclusion of some of the key groups who use it, like open source database developers and JDBC driver developers. The difficulty of accessing the released standards documentation is another store point.

For users without corporate backing to buy $lots copies of the standards it is vary frustrating to have to rely on circulating old drafts and other vendors' documentation. This devalues the standard, because it's so hard to know what is and isn't standard that it's hard to code to the standard - so people just pick a vendor dialect and stop caring.

Personally, I think the best thing that can happen to the SQL standards process at this point is to put it quietly out of its misery and reboot the whole thing. We - end users, database implementers, middleware/ORM implementers, JDBC/ODBC/ADO/etc driver implementers, etc - need a language with the same core capabilities but a sane, machine-readable syntax. SQL's god-awful pseudo-natural-language monstrosity of a grammar is a nightmare to work with. Parsing it is hard enough, but transforming it and proving things about it is horrifying. I'd be delighted to see adoption of a language that could express all the concepts, but:

- Is ordered sanely, with subjects before predicates before outcomes;

- Is easily represented as an easy-to-work-with in-memory tree (like a DOM or similar, but hopefully not XML) for easy transformation and composition;

- Is designed to be composed from smaller pieces, so it's easy to shuffle around subqueries, predicates, etc without messing with the stupidities of "AND" and commas;

- Is capable of expressing the same queries and plans (for easy porting) so it still has inner, left outer, right outer, and full/cross joins, is still relational, still supports grouping, aggregation, windowing, etc;

- Gets rid of all pseudo-function language syntax in favour of using true functions or a generic and extensible expression structure that doesn't require syntax changes for every new feature like CTEs, window functions, etc;

- Is designed WITH THE ACTIVE INVOLVEMENT OF PEOPLE WHO IMPLEMENT JDBC/ODBC DRIVERS, and PEOPLE WHO HAVE IMPLEMENTED LANGUAGE INTEGRATED QUERYING OR CRITERIA APIs. This is a big one. The amount of suffering that SQL causes for JDBC driver developers cannot be understated, and they get off easy compared to the poor individuals who try to produce programmatic query builders/criteria APIs/language integrated querying like JPA 2.0 criteria, LINQ, etc.

- ... and most importantly, because it's a saner way of writing the same queries as SQL, can be transformed into SQL to be sent to backends that don't support it yet, so the chicken-and-egg problem of adoption vs support can be resolved.

Most current efforts like Muldis-D seem to miss the last point - that if you want adoption, you're going to need to be able to transform to SQL in the medium term so people can use it on platforms that don't yet support the new, saner language.