From what I can see, you're currently using the same kind of tricks (table_info) as the SQL::Translator::Parser::DBI::$Driver modules. These have also worked for me in the past. Basically instead of passing them DDL in a big string, you give them a DSN, username and password (an open database handle works too). Then SQL::Translator::Parser::DBI selects the appropriate $Driver, which goes and fetches the metadata directly from the database.

If you have enough permissions to use table_info, you have enough permissions to use the DBI parsers.

The doc for the DBI parser says that Oracle is not supported and Pg support is experimental, but if you look at the module list for the distribution there *is* a DBI::Oracle class, so the doc is probably out of date. I'd say, install SQL::Translator, play around on real databases, see if it fits your needs.

I have just tried out what you wrote in your last post and I like the idea of doing it this way. To be more specific what I tried out was:

use strict;
use warnings;

use DBI;
use SQL::Translator;

my $dbh = DBI->connect( 'dbi:Pg:dbname=playground', 'postgres', '*****
+**' );

my $translator = SQL::Translator->new(
    parser      => 'DBI',
    parser_args => { dbh => $dbh, }
);
$translator->translate();

my $schema = $translator->schema;
for my $rsrc_name ( $schema->get_tables() ) {
    my $rsrc = $schema->get_table($rsrc_name);
    ...
}
...
[download]

The Pg support indeed is not complete, I had tested with a table having a two-column primary key and the parse() method of SQL::Translator::Parser::DBI::PostgreSQL failed (currently it only works on one-column pkeys).

I have posted a bug report and a proposal for a patch on rt.cpan.org (see here). The bug was easy to fix. So one possibility would be to continue with my database-wise handling and the other to help out finding and maybe help fixing remaining bugs in the SQL::Translator::Parser::DBI::XXXXX modules.