I think views and tables should not be treated differently. For almost every purpose, they are same. PostgreSQL ODBC driver certainly doesn't make these distinctions.
On Fri, 16 Nov 2001, 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. > > 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. > > >
