> If table_info doesn't return the string you need to use, then you do > need a method to convert what table_info does supply into a format that > you can use. table_info, like most (if not all) meta-fata methods returns returls as a recordset, with the seperate portions of the identifier represneted as distinct columns, hence no need to delimit the identifier. This is standard across every DBMS and API I have come across.
Providing the quote_identifiers functionality (and other features such as quote, tables and chopblanks) makes DBI what it is, a more useful and more platform independant than any other DB API I know. You don't need to use this extra functionality if you don't want to. > If > DBD::Informix is told to quote one of those names, however it was > obtained, and the DELIMIDENT variable is not set (was not set when the > connection was created), then blindly quoting the name can lead to the > wrong results: > > WHERE "column name with blanks" > 'abc' But the quote_identifiers method should not blindly quote the name. The DBD should take account of the current state for the underlying DBMS's DELIMITED variabel (or equivalent) and take appropriate action. > I'm still not sure that if table_info and/or tables does not return the > correct syntax (and pointedly ignore anything that cannot be handled > correctly), then you will run into trouble. table_info() works correctly: there is no need to quote distinct identifiers. Currently, tables() does not work correctly as it returns a hacked complex identifier. The proposed method, if implented properly, at the DBD level would fix things for tables() and any other method that needs to build complex identifiers. > Another nasty - what about > a regular table name that has column names that must be quoted. A > simple perusal of the tables part of the system catalog is not > sufficient. I don't understand this. How can a table name have column names? -- Simon Oliver
