On Sun, Feb 22, 2004 at 04:22:47PM -0000, Greg Sabino Mullane wrote: > > > I still don't quite follow you. How does it differ to what the > > default primary_key() method does. > > The default as I understand it is to have a single number in the > KEY_SEQ field and a single name in the COLUMN_NAME field. That is > why (I presume) the ORDER BY in DBD::Oracle for primary_key_info() is: > > ORDER BY TABLE_SCHEM, TABLE_NAME, KEY_SEQ > > The only way to explain the KEY_SEQ in the ORDER BY is to assume > that more than one row per (unique) table is returned. The first two > elements in the ORDER BY are a bit suspicious come to think > of it, as primary_key_info is not supposed to accept search > patterns and return info for a single table.
That's the way the spec is. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odch21ipr_4.asp > So the question is, what is the standard for multi-column keys. > Return multiple rows with a single value in each column? Yes. I've added this to primary_key_info() docs: The statement handle will return one row per column, ordered by TABLE_CAT, TABLE_SCHEM, TABLE_NAME, and KEY_SEQ. > One final question related to these methods: is there a preference > for ODBC vs. SQL/CLI? I notice that DBD::Oracle uses the former > for primary_key_info and the latter for foreign_key_info. I would > prefer the latter for everything myself, but we should probably be > consistent and allow the user to change it with a flag. I don't think the DBI docs mandate SQL/CLI for foreign_key_info. It's just pointing out that a driver may return a statement handle where $sth->{NAME} may have either set of column names. Tim.
