in reply to drawbacks to 'eval' parameters/placeholders/binding in DBI calls to mysql database

I didn't realize how bad your code was when I wrote my earlier reply. I'm not trying to rude. I think you'll agree with me after you see what follows.

Your bad and buggy way of building an array:

sub to_literal { "'$_[0]'" } my $x; for (...) { if (!$x) { $x = to_literal($_); } else { $x = join(', ', to_literal($_)); } } my @a = eval $x;

Still bad, but bugs removed:

sub to_literal { "'\Q$_[0]\E'" } <--- my $x; for (...) { if (!defined($x)) { <--- $x = to_literal($_); } else { $x = join(', ', to_literal($_)); } } my @a = eval $x;

A good way of building an array:

my @a; for (...) { push @a, $_; }

Bonus: It doesn't stringify everything.

Useful functions: push, pop, shift, unshift, splice

Update: I initially had the loops flattened, but I thought that would cause confusion.
Update: Added links.

  • Comment on Re: drawbacks to 'eval' parameters/placeholders/binding in DBI calls to mysql database
  • Select or Download Code

Replies are listed 'Best First'.
Re^2: drawbacks to 'eval' parameters/placeholders/binding in DBI calls to mysql database
by nextguru (Scribe) on Aug 20, 2009 at 23:07 UTC
    I coded the test routine very late last night and couldn't seem to write this in a simple way (think of forest/trees analogy). This is a much clearer (and now quite obvious) method. Thanks for the help.