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
