Coping with 'C' vs 'newC' function language names

Philip pointed out awhile back that it does not work to load a 7.0.*
dump into current sources if the dumped database contains any
procedural language definitions.  The dumped handler-function
definitions will look like

CREATE FUNCTION "plpgsql_call_handler" ( ) RETURNS opaque AS
'/opt/postgres/lib/plpgsql.sl' LANGUAGE 'C';

which was correct for 7.0.* ... but under 7.1 the handler functions
use the new-style function manager API and therefore need to be
declared as LANGUAGE 'newC'.  The system has no way to detect
this mistake, so you only find out when your plpgsql functions
crash :-(

Something's got to be done about this --- not being able to load
7.0 dump files will not do.

The best kluge I've been able to think of so far is to hardwire
into CREATE FUNCTION a check for "plpgsql_call_handler" and the
other existing PL handler function names, and force the language
to be taken as 'newC' for these functions even if 'C' is specified.

At one time I had toyed with the idea of using 'C' to specify
dynamically-loaded functions that use the new-style fmgr API, and
'oldC' for old-style fmgr API.  That would be nicer in the long run,
and it'd fix this particular problem, but it'd break dumped definitions
for user-defined C functions that haven't yet been updated to new-style
API.  That doesn't seem like an acceptable tradeoff.

Has anyone got a better idea?
        regards, tom lane