I'm working on patching DBD::Pg to fully support more of the metadata
functions. I've gotten most of them outlined in the DBI spec working, but
there's a few issues I'm not overly clear on.
tables() is meant to be a simple interface to table_info(). I took this a
bit further and have it only returning userspace tables and views by
default.
table_info() on the other hand is for detailed information. To this effect I
figured it should return all the types (TABLE, VIEW, SYSTEM TABLE, custom
types, etc.) by default.
You'll notice I said 'by default'. Either can of course return whatever you
want if you explicitly declare it. I felt having tables() work that way was
a bit more DWIMish; I imagine most people calling it simply for a list of
everyday tables. This means table_info()'s return is 'out of sync' with
tables() though.
While the spec states how the return is to be formatted, it doesn't
explicitly state what's to be in the return. I was wondering which way
others have gone and your thoughts on this.
Thanks,
Arguile
Side note:
----------
I might as well raise an issue that's been bothering me about the metadata
function. A lot of the ODBC spec seems to map awfully to Perl. I mean, look
at the table_info() function.
The value of $type is a comma-separated list of one or more types
of tables to be returned in the result set. Each value may optionally
be quoted.
$sth = $dbh->table_info( $catalog, $schema, $table, $type );
I mean, really! The people who wrote the ODBC spec have obviously never
dealt with an array refference ;). I commend DBI for staying to spec, but
would it be possible to allow this as well?
$sth = $dbh->table_info( $catalog, $schema, $table, \@types );
Ahhh, now we're talking. The first thing most drivers I've looked at do is
trim the string and split// it into an array; so allowing both would give
much greater flexibility, and a more Perlish feel to the function, while
only requiring DBD writes to add a simple if-else check (UNIVERSAL::isa(),
ref(), etc.).
If I'm way off base feel free to say so.
