-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> I agree. When you get down to it, schema/table/etc reverse > engineering is a very complicated and involved process. Fetching > lists of tables or columns etc should no more be built in than SQL > parsing or generating. In short, anything that can normally be > fetched or changed using ordinary SQL statements should be left out > of the DBI core It's already out of the core though - it's the DBDs responsibility to do the heavy lifting - DBI just provides a set of skeletized methods. > On a similar note, utility functions like quote() should be left out > of the DBI core, and left to either a separate module or someone's > wrapper, since it's firmly related to SQL generation. If people want > DBI itself to handle stuff like that for them, they should use host > parameters for the literals in question. They should be handled by the DBDs, but I don't really think the default method in DBI really does any harm (it's simply a s/'/''/g after all :) I do agree that things like preparse() are perhaps going a bit too far. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200507112009 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFC0wqVvJuQZxSWSsgRAiOoAJ48g3GjHCYXlpSnLgDGi9q2uAfOgACfWyGH uOPROT8dgCcNyakfe9icOXo= =D5zv -----END PGP SIGNATURE-----
