Hi Jeff, because you didn't answer my last reply I think it's better to send the 2nd bug fix (patch includes fixes sent last times, too) again via dbi-users@ list. When you're short on time, maybe others who are involved, may take a look on it. Furthermore SQL::Statement and a lot of DBD-Modules seems to rely on the other, when both modules are installed.
I made a fix in join_2_tables which prevents detecting the shared columns
as soon as more than 2 tables shall get joined. To be honest, I can't see
any reason for checking $isunqualA{$c} or $isunqualB{$c} in lines 663 and
666. Because of 2 tables could have similar named columns, the check of
k1/k2 in %iscolA/%iscolB is more significant. That's the reason why I
can't understand the lines 659-661 - a check as done in 663/666 is enough,
isn't it? In the first impression (without deep think over it) it looks
like a forgotten relict from first steps in joining into MemTables. But
maybe it's important for NATURAL joins - what ever that means - I'm not an
SQL expert as you.
Other problems - I didn't fix, because don't know where - is the behaviour
of SQL::Statement/SQL::Parser on following queries:
1) select A, B from tA, tB where tA.ID=tB.A_ID and tB.PK="PATTERN"
2) select A, B from tA, tB where tA.ID=tB.A_ID and tB.PK='PATTERN1' or
tB.PK='PATTERN2'
Both statement prints out a perl warning like:
1) Use of uninitialized value in substitution iterator at
/usr/lib/perl5/vendor_perl/5.8.5/SQL/Parser.pm line 1806.
2) Use of uninitialized value in substitution iterator at
/usr/lib/perl5/vendor_perl/5.8.5/SQL/Parser.pm line 1552.
#ERROR: error during query: 'SQL ERROR: No equijoin condition in WHERE or
ON clause
The 1st situations causes SQL::Parser to bail out when hit the "PATTERN"
arg without raising any error.
I think better error checking could works wonders xD
Let me ask the question from my last mail again: What do you think about
allow indexed table-access? It's very likely that a physical data
structure knows more performant ways to search in it's data pool (XPath in
XML, BTrees in Berkeley-DB-tables, we use reverse lookup hash-tables).
When I shall invest time to add the one or other bug-fix or feature as
suggested, I ask for being allowed to reformat the source. It's very
painful to edit, because sometimes are TAB's used, sometimes blanks, no
consistent indent etc. `perltidy -gnu` or `perltidy -toc` would allow me
to stop wasting time to reformat the source when editing around to program
sth. and format back when finished to reduce differences made only because
of beautifying ...
Freundliche Grüße / Best Regards
Jens Rehsack
_________________________________________
Fa. Manß & Partner
Phone: +49 - 214 - 30 - 46 193
Fax: +49 - 214 - 30 - 31 625
E-mail: [EMAIL PROTECTED]
Web: http://www.BayerBBS.com
Geschäftsführung: Vorsitzender Andreas Resch | Arbeitsdirektor Norbert
Fieseler
Vorsitzender des Aufsichtsrats: Klaus Kühn
Sitz der Gesellschaft: Leverkusen | Amtsgericht Köln, HRB 49895
patch-SQL_Statement
Description: Binary data
