Great. Thanks Brandon! Tim.
On Mon, Jun 12, 2006 at 08:10:39AM -0500, Brandon Black wrote: > On 6/9/06, Tim Bunce <[EMAIL PROTECTED]> wrote: > >On Fri, Jun 09, 2006 at 11:55:01AM -0500, Brandon Black wrote: > >> > >> One method that I'd like to see, but which doesn't exist yet, is a > >> "unique_key_info" similar to "primary_key_info", which after being > >> released in the DBI dist, the DBD authors could work on supporting > >> like they do "primary_key_info". Has this idea been shot down before? > >> Is anyone already working on it? Would you mind me working up a > >> patch for this and sending it in? > > > >Sure! > > > >Start by finding out what the equivalent ODBC function is (I don't know > >offhand) and model the new method closely on that - in the same way as the > >other schema metadata methods are modeled closely on their ODBC > >counterparts. > > > >Thanks! > > Apparently ODBC doesn't support the explicit notion of a UNIQUE key, > or "alternate key", > or anything else of the sort. However, it does have a function > "SQLStatistics", which happens to report stastical information > (cardinality + # of pages) for a table and its indexes. > > >From this interface one can also see the ordered list of columns in > each index and whether the index is UNIQUE or not. There's also a > flag to tell it to not waste time generating the actual statistics if > they aren't readily available, in the case that the index definitions > are all that is important to the caller. It seems the best tool for > the task ODBC-wise, and it is fairly straightforward and obvious that > one could/should use this to find UNIQUE index definitions. > > I've tenatively started down this path: a statistics_info method that > mirrors ODBC SQLStatistics interface, and looks a lot like the other > metadata methods in form and function. Much like primary_key_info, > there probably won't be a default implementation, so the DBI part will > just be the documentation of the interface, and I'll go and implement > it for at least one of the DBDs (probably DBD::Pg) just to see that I > can make it work sanely and provide a reference implementation. > > -- Brandon > >
