Re: thorny problem with table_info implementation

On 03/09/13 09:38, Tim Bunce wrote:
> On Mon, Sep 02, 2013 at 08:53:18PM +0100, Martin J. Evans wrote:
>> On 02/09/2013 20:27, Martin J. Evans wrote:
>>>
>>> Now, table_info() with no arguments is not mentioned in the DBI pod so
>>> you could say that is undefined behaviour but it is a little late for
>>> that now as DBD::ODBC uses it in test code and as far as I know, so do
>>> others. However, to fix the initial bug I cannot know when empty strings
>>> are supposed to be undef/NULL and when they are supposed to be empty
>>> strings. So I can fix the bug as shown but only if I change DBD::ODBC
>>> test code from table_info() to table_info('%', '%', '%', '%') and I
>>> cannot change anyone elses code.
>>
>> Correction, in that last paragraph (I did warn you), I should have
>> said table_info() to table_info('%', '%', '%') i.e.,
>>
>> table_info('%', '', '') returns catalogs only
>> table_info('', '%', '') returns schemas only
>> table_info('', '', '', '%') returns types only
>> table_info('%', '%', '%') returns everything
>> table_info() did return everything due to workaround in DBD::ODBC
>> but fixing bug ends up in table_info() returning nothing.
>
> How about changing your test code to table_info('%', '%', '%', '%')

because that does not work. It would need to be table_info('%','%','%') (or table_info(undef, undef, undef, undef) for it to work. In ODBC the table type needs to be null or all types to get everything. Obviously changing the test code is easy.

> and treat table_info() a special case that triggers a warning?

hmm, I warned I might be having a bad day. As soon as I read that I thought how do I do that as I'd forgotten there is a table_info method in DBD::ODBC itself. It appears all the problems are DBD::ODBC specific as I missed the code that set the parameters to q{} if not defined.

> Tim.
>

Thanks and sorry for noise.

Martin