FWIW, I have previously sketched a "syntax rewriter" of sorts: a simple filter which is applied to input before the lexer even sees it. Quite some "syntax magic" can be achieved by allowing an extension to *hook* into this functionality in order to do some rewriting; If turning one statement into several (multi-statement) is also allowed quite some serious emulation could be achieved.
Some DBMSes have hooks that let you match statements to patterns and/or by hash and replace them with a wholly different statement. It seems to be a feature to work around applications that've fossilized completely, with source code long lost or binaries provided by a vendor who went out of business years ago. Or cranked their prices for the new version. Or, of course, where the apps team have built a fort with spiked pits, a portcullis, and a molten lead trap between their office and the DBA team's office, where the DBA team crouch behind desks covered in woad clutching their swords and knives. Treaty negotiations have entirely fallen through and they throw rocks instead of talking to each other.
The idea is that in such delightful situations where you can't/won't fix terrible queries in the application you instead match them in the DBMS and transparently rewrite them.
I hear "but we can't change the application" often enough to understand why such hooks exist, but not often enough to particularly want them in PostgreSQL.
I can certainly prepare a small patch for the first commitfest of 9.7 if this sounds viable.
I'd be surprised if it was popular. It's hard to imagine a way to do it robustly when dealing with pre-lexer input, unless you're doing simple pattern matching to identify and replace whole statements.
