Ah, but friedo isn't importing, either. He's creating an object, a very expensive create, and returning that. This way, require still works as well.

Actually, given the way this works, I would be tempted to suggest the following changes:

• Cache the object. The second time Alex::Log->new is called, return the same object. This kills inheritance, mind you, so as long as you don't derive new packages off this one, it will at least allow the second and further instantiations to not query the database.
• The no strict 'refs' line has a significant scope. By saying

  my $sub = sub { ... };
  no strict 'refs';
  *{"Alex::Log::$name"} = $sub;
  [download]

  you've just reduced the scope of the dangerous behaviour to just the one line that we want to use it.
• I think your truncation is a bit off - you then add a bunch of stuff to the front after truncation. I think you probably want to add the stuff prior to truncation.
• Heck, I'd just take that subroutine out altogether and have everything passed in:

  sub _doLog {
    my ($self, $lid, $pid, $msg) = @_;
    $msg = '[PID:$$] ' . $msg;
    substr($msg, 2045) = '...' if length($msg) > 2048;
    my $sth = $self->{dbh}->prepare("INSERT INTO Logs
                                     ( log_level_id, 
                                       log_program_id, 
                                       message ) 
                                     VALUES ( ?, ?, ? )" );
    $sth->execute( $lid, $pid, $msg );
  }
  [download]

  And then your dynamic code would be more like:

  my $singleton;
  sub new {
    return $singleton if $singleton;  # bypass setup if already done
  
    my $class = shift;
    my %args = @_;
  
    croak "No program name given to constructor. 
              ( program => 'foo' required )"
      unless exists $args{program};
  
    my $pname = $args{program};
  
    my $dbh = Alex::DBI->new;
    my ( $pid ) = $dbh->selectrow_array( "SELECT id FROM Log_Programs 
                                          WHERE name = '$pname'" );
  
    croak "Program $pname not in database" unless $pid;
  
    $singleton = bless( { dbh => $dbh }, $class );
    my $levels = $dbh->selectall_arrayref( "SELECT id, name 
                                            FROM Log_Levels" 
  
    foreach my $lev( @$levels ) {
      no strict 'refs';
      *{'Alex::Log::' . $lev->[1]} = sub {
        shift->_doLog(@$lev, @_);
      };
    }
  
    $singleton;
  );
  [download]

• At this point, we can almost get rid of the object. Rather than using "new", we call it "_initialise". Otherwise, it can work pretty much the way it is. And then the dynamic setup would become:

    foreach my $lev( @$levels ) {
      no strict 'refs';
      *{'Alex::Log::' . $lev->[1]} = sub {
        _doLog(@$lev, @_);
      };
    }
  [download]

  And then _doLog would become:

  sub _doLog {
    my ($lid, $pid, $msg) = @_;
    #...
    my $sth = _init()->{dbh}->prepare("INSERT INTO Logs
                                       ( log_level_id, 
                                         log_program_id, 
                                         message ) 
                                       VALUES ( ?, ?, ? )" );
    #...
  }
  [download]

  And then we can import everything. Here's a tricky thing. Maybe this would do:

  our @EXPORT_OK;
  use base 'Exporter';
  
  sub import {
    _init();
    goto \&Exporter::import;
  }
  [download]

  And then, in the _init function, we change:

    foreach my $lev( @$levels ) {
      push @EXPORT_OK, $lev->[1]; # set up the allowable exports
      no strict 'refs';
      *{'Alex::Log::' . $lev->[1]} = sub {
        _doLog(@$lev, @_);
      };
    }
  [download]

  And now you can just call the functions from your code directly, without the object. Change @EXPORT_OK to @EXPORT if you really want to import 'em all, otherwise call as use Alex::Log qw(level1 level2 level4);

Thanks for the suggestions, Tanktalus! I really don't want to go the Exporter route with this since I already have a significant amount of namespace invasion going on in other places. But I think caching the object is definitely a good idea, as is reducing the scope of the no strict.