Open points to discuss for DBD::File 0.39

Hi DBI and DBD developers,

I have some open points for DBD::File I'd like to ask for feedback on them.

The first two are related to the table meta data.

1) I introduced simple getters and setters for DBD::File table's meta
    data (look for get_file_meta and set_file_meta in
    lib/DBD/File/Developers.pod). Merijn and me came over to extend
    this interface with some wild cards:
    - '.': default - read, the attributes of the database handle is
           delivered/modified (even through a proxy, which was the
           primary intention)
    - '*': all - the attribute of all tables (and the default one)
           is modified
    - '+': as '*', but restricted to all ANSI conform tables names
           (default isn't touched)
    - qr//: all tables matching the regex are affected

   The question is related to the getter: how should the attributes being
   returned (or more: what API should be supported)?
   Let me explain a bit deeper the cause of the question. set_file_meta
   can be called using the table_name as first argument, the attribute
   name as second one and the new attribute value as third argument.
   It sounds reasonable to allow following call, too:

   $dbh->func( $tname, { attr1 => val1, attr2 => val2 },
               'set_file_meta' );

   Consequently get_file_meta should be able to return more than one
   attribute, shouldn't it? So we have 3 situations for get_file_meta
   regarding the expected return values:
   a) 1 table, 1 attribute - expected return value is a scalar
   b) n tables, 1 attribute - expected return value is a hash of
      table names pointing to the scalar value of the attribute
      belonging to that table
   c) n tables, m attributes - expected return value is a hash of
      table names pointing to a hash of attribute names containing
      the attribute values of the affected table

   I rate it to complex in API and need external thoughts :)

2) backward compatibility of depreciated structures per table of DBD::CSV,
    DBD::AnyData (and maybe later DBD::PO or DBD::DBM). DBD::CSV had a
    structure $dbh->{csv_tables}{$tname}{...} - which is now handled via
    $dbh->{f_meta}{$tname}{...} ... - DBD::AnyData had the same with
    $dbh->{ad_tables}{$tname}{...}.
    Both had several attributes in their which were not synchronized
    between both DBD's. Further, the $dbh->{f_meta} structure contains
    the table names after they walked through an internal filter
    (suggested by mje) which handles the identifier case. An additional
    structure $dbh->{f_meta_map} is used to hold the map between the
    original table name (from SQL statement or through the getter/setter)
    and the internal used identifier.

    Because it could be very difficult to manage backward compatibility
    there, I would like to have a solution which can be plugged in as
    early as possible:
    a) $dbh->{csv_tables} or $dbh->{ad_tables} should become a tied hash
       which access the table's meta data using the get_table_meta method
       from the table implementor class.
    b) further, the meta data which can be accessed through this tie
       should be tied, too - to allow overriding FETCH/STORE methods which
       could handle the mapping between old attribute names and new
       attribute names.

    While I rate being 2a more important than 2b, I would like to get
    feedback for both ideas. Discarding 2a could result in inconsistent
    entries in $dbh->{f_meta} which could lead the DBD into unpredictable
    behavior.

My third question has lesser implications :)

3) Merijn and me had the idea to let the users decide on connection
    whether to use DBI::SQL::Nano or SQL::Statement - not globally via
    DBI_SQL_NANO environment variable.

    Because of the handling of the handles for the dr, db and st
    instances of a DBD I hoped to get some suggestions how we could
    implement a similar behavior for DBD::File::Statement and
    DBD::File::Table.

Thanks for all answers in advance,
Jens