Lazy initialization of plugin-manager in DBD::Sys (on a feature request of Matthew Trout)

Hi *,

I got a feature request from mst to reduce dependencies of real-world
installations of DBD::Sys.
He asks, if it were possible to use only those plugins/tables, which
are already loaded by the
user before
    DBI->connect( "DBI:Sys:", undef, undef, {
        sys_pluginmgr_restrict => 1,
        sys_plugin_restrict => 1
    } );
is called.

I decided it's a good requirement and going to implement it and
detected a conflict (from my point
of view). When DBD::Sys connects (it's a DBI::DBD::SqlEngine derived
DBD), following happens:

1) a new object is instantiated (DBI::_new_dbh)
2) the default initialization is executed
(DBI::DBD::SqlEngine::init_default_attributes)
2a) $dbh->{*_valid_attrs} and $dbh->{*_readonly_attrs} are filled by
the DBD::*::db::init_valid_attributes methods
3) default values for some attributes are set
4) the dsn is parsed by DBI::DBD::SqlEngine::dr:.connect and the found
attributes are set
    at this time, $dbh->STORE already proves against
$dbh->{*_valid_attrs} and the readonly one's.
5) DBI::connect sets the key/value pairs of (above showed) the connect attrs
    at this time, $dbh->STORE already proves against
$dbh->{*_valid_attrs} and the readonly one's.
6) DBI::connect calls $dbh->connected

Following call must fail, when the plugins are lazy evaluated:
    DBI->connect( "DBI:Sys:", undef, undef, {
        sys_pluginmgr_restrict => 1,
        sys_plugin_restrict => 1,
        sys_openfiles_pids => $$,
    } );

It's because the table attributes are retrieved from the table plugins
while they are loaded and
cataloged by the plugin-manager.

A suitable workaround could be to load the plugin manager immediately
when an unknown attribute
with the right prefix is detected - but hashes are unsorted and
"sys_openfiles_pids" could be
evaluated before "sys_pluginmgr_restrict".

Of course, I could force the user to set all table related attributes
after the connection is made,
but this will cause an incompatibility with DBI_AUTOPROXY=dbi:Gofer:

I don't like the idea to store simply everything what begins with
"sys_" - I planned to keep the
smart infrastructure of meta-dbd attributes (introduced by Jeff Zucker?).

Any ideas?

Thanks in advance,
Jens