> $dbh->func([ > [ 'tableA', 'DBM', 'file1.dbm' ], > [ 'tableB', 'DBM', 'file2.dbm' ], > [ 'tableC', 'CSV', 'file3.csv' ], > ,'ad_catalog');
That would work too, I had assumed one handle per database/table/DBM I suppose one could also provide another argument declaring what column name the DBM key maps to, if it felt that was necessary. >I am not at all in favor of inventing arbitrary limitations to the SQL. >I would prefer to see this worked out behind the scenes -- if the user >supplies a well constructed query, it will be optimized and if they >don't, it won't be. That's how most database implementations work. >Basically the docs would advise users to start out with "WHERE key = >value AND ..." but if they ignore that or have other kinds of querries >they need to perform, they could do it, but slower. Fair enough, but I'd make that the third run, that is these are steps in the development process, adding additional features as it goes along. Especially since, even without a little consideration, a good design will not make it difficult to add this functionality in steps. Also in case it's unclear this is "WHERE key1='foo' AND key2='bar'", "WHERE key1='foo' OR key1='bar'" would of course be legal for the 2nd and even first rev. -- H4sICNoBwDoAA3NpZwA9jbsNwDAIRHumuC4NklvXTOD0KSJEnwU8fHz4Q8M9i3sGzkS7BBrm OkCTwsycb4S3DloZuMIYeXpLFqw5LaMhXC2ymhreVXNWMw9YGuAYdfmAbwomoPSyFJuFn2x8 Opr8bBBidccAAAA= -- MOTD on Setting Orange, the 7th of Discord, in the YOLD 3168: I'm a message/digest guy in a text/plain world --JP
