First, this is rather vague. I don't know how complex SQL you have to support and you have to figure that as soon as you implement one feature someone else will say they can't live without another feature.

What you are essentially talking about is implementing an in-memory db in Perl. this is not likely to remain "easy" or "only using modules in the standard library" for long and it is critically important that you inform $management of these problems before you get started. Let them figure out what they *really* want from this. Otherwise you will end up trapped in a hole that will just keep getting deeper and $management will decide that the way out is to tunnel to $antipode.

Now this being said, the next thing is to say that if you are going to support it, you are only going to support very simple searches in the form of SELECT column_list FROM table_name WHERE condition. From there simple parsers should be possible using regexps. Note that this is a *tiny* subset of SQL and if they want anything else, or to be able to have a column named "from" (not an unreasonable request) you are going to need something like Parse::RecDescent and restart this from scratch. Basically at that point, you get into hierarchy of language problems.

However, my advice is that before you do this, stop, and have the difficult discussion with your boss. Inform him of what the real problems are, and that this will involve reinventing lots of stuff from CPAN if it goes beyond basic parsing with a total prohibition on use of reserved words as names. $management gets paid to make the decisions. Let them make it. But make sure that they know what they are getting into....