On Jan 12, 2004, at 8:07 AM, Harry Jackson wrote:
Dan Sugalski wrote:
Having a fetchrow_hash that returned a Hash where the keys are the column names and the values are the column values would be most of the rest.
I read somewhere that accessing a hash was slightly slower than accessing and array which is one reason why I never used it. The other reason is that if I name the fileds in the hash then the user needs to know the names to access them or perform some magic to get them.
The names will be known--they are the column names (or aliases) used in the query.
select * from table_name
This does not tell me the names of the tables or anything about the order they are going to come out in.
The nice thing about a hash (that I've found when using DBI) is that you don't have a problem if you end up inadvertently changing the order in which the columns are returned, when modifying a query.
That is one advantage I never thought of and a fairly good one.
Hopefully the actual strings used as the keys can be re-used. (That is, each hash can use the same string instance for a given key. I believe that Perl5 does this for hash keys.)
Yes inded they can, it was a bit short sighted on my part not noticing this although the fact the exist is overhead but that is just me being pedantic ;-) I am currently working on a way to do it at the moment.
Could someone tell me who exactly will be taking advantage of this library ie at what level are we pitching it at. I seriously doubt that most developers are going to even see the implimentation of this, rather its the guys coding drivers etc in which case its those guys that are going to be worried about the user interface. Or am I off the mark here.
Harry
