chip, merlyn, and tilly (and anyone else, I suppose):

Some of the ideas listed here set me to thinking. What would be the implications of creating a separate package just for the row data and using that instead of a hash? That is pretty much what I am doing now, except referencing main:: instead of another symbol table.

Some things I am concerned about:

• Memory usage in creation a second package in a perl program
• Speed of calling variables longhand from other packages (ie, $Foo::Bar::zot)
• Anything in a similar, pragmatic vein... :-)

If you folks think it's feasible, I'll generate a couple thousand records of junk data and do some benchmarks this weekend.

Alakaboo

That makes the variable name collision less likely, but what if you pick a package name someone else is using? (If your code ends up in a module somewhere and someone else uses it, there's a possibility.) Plus, it means your template variable references will require package name prefixes. (I suppose you could also put a package statement and the templating sections within a block.)

I doubt it's as efficient as just using the fetch hashref method, but I don't have numbers to back that up. You'll still have potential typos to deal with (in your template), and symbolic references (for little gain, in my opinion), and you'll have to write more documentation on what's going on (and hopefully why) for yourself and future potential maintainers.

I don't think this technique is going to save you anything over the method DBI already provides, in the long run.

In all probability, you're right. I'm trying to design a hack for a hack for a hack (or something along those lines) and I'm being stubborn and insolent by proceeding along this thought line. :-)

However, I should point out that the DBI author describes a 1:4 decrease in performance when switching from fetch (binded columns) to fetchrow_array. I'm not sure where fetchrow_hashref sits in relation to fetchrow_array, but I don't doubt it's as-bad or worse.

On the other hand, he also says that this is due to the limitations of Perl and how it handles memory, and not because of DBI or the database engine. So it's doubtful that this method will gain anything over fetchrow_hashref, as you said. But maybe it's work checking out.

I have no qualms about writing $a::name instead of $a->{name} if it's four (or even two) times faster. This also deserves to be compared to a standard bind_columns routine, and the fetchrow_arrayref ($a->[0]) method. There's very little doubt in my mind that bind_columns is fastest, followed by arrayref, hashref, then array. I'm just curious to see where this technique fits in, and if it can be adapted to increase A) readability in situations where fetchrow_arrayref is being used, and B) speed in situations where fethrow_hashref is being used.

<goes to dust of the ol' test tubes>

Alakaboo

Personally I would prefer the syntax of a pseudohash if it needed some sort of declaration, IMO it is too bad that the technical advantages of that interface was not realized earlier. :-(