-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> 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.
So the question is, what is the standard for multi-column keys.
Return multiple rows with a single value in each column? Return a
comma-separated list? A space-separated list? The latter two would
require possibly quoting the COLUMN_NAME entries of course. FWIW,
we also have a third way, which is to return COLUMN_NAME and company
as an arrayref. Definitely not standard, but useful.
> I'll add \%attr to all the metadata methods that don't have one.
Thanks. 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.
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200402221102
-----BEGIN PGP SIGNATURE-----
iD8DBQFAONdEvJuQZxSWSsgRAm+OAKD7ftBz0M4AZQEayhuDSjiCKJcdbQCgxAhg
xfrKOeogXzJeXoFzA2vzpXE=
=9aei
-----END PGP SIGNATURE-----
