On Fri, Nov 16, 2001 at 03:04:50PM -0800, arguile wrote: > 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.
That's something we should discuss an API for in dbi-dev. > 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. Yeap. > 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. Yeap, hence the need to discuss it. I'm not adverse to having the default DBI implementation of tables() filter out SYSTEM tables and views but I'd like a way to also try passing that exclusion to table_info(). The issue is tricky for Oracle (and maybe some others) because there are also synonyms (aliases) that may be user or system owned, public or private, and point to user or system tables. So, for example, all the 'day to day' tables that a user is expected to work with may actually be provided as public synonyms to tables in another schema. > 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. It says "This list should include all tables that can be used in a C<SELECT> statement without further qualification." > 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. How often, in real life, would $tables not be a simple string constant? Tim.
