What I'm actually more concerned about, in this whole line of development, is the follow-on requests that will surely occur to kluge up Postgres to make its behavior more like $whatever. As in "well, now that we can serve MySQL clients protocol-wise, can't we pretty please have a mode that makes the parser act more like MySQL". If we start having modes for MySQL identifier quoting, Oracle outer join syntax, yadda yadda, it's going to be way more of a maintenance nightmare than some hook functions. So if we accept any patch along this line, I want to drive a hard stake in the ground that the answer to that sort of thing will be NO.
Actually, a substantial amount can be done with hooks. For Oracle, which is substantially harder than MySQL, I have a completely separate parser that generates a PG-compatible parse tree packaged up as an extension. To handle autonomous transactions, database links, hierarchical query conversion, hints, and some execution-related items requires core changes. But, the protocol and parsing can definitely be done with hooks. And, as was mentioned previously, this isn't tied directly to emulating another database - it would enable us to support an HTTP-ish interface directly in the server as an extension as well. A lot of this can be done with background worker extensions now, which is how my stuff was primarily architected, but it's hacky when it comes to areas where the items Jan discussed could clean things up and make them more pluggable.
Assuming we're going to keep to that, though, it seems like people doing this sort of thing will inevitably end up with a fork anyway. So maybe we should just not bother with the first step either.
Perhaps I'm misunderstanding you, but I wouldn't throw this entire idea out (which enables a substantial addition of extensible functionality with a limited set of touchpoints) on the premise of future objections.
