I looked at your code, and yes, I want to suggest a different way, to organize them.

Generally speaking, I don't like to mix data with code. In your case, I would look at your sql statements as data, when I take your Perl scripts as code.

But I don't agree with your boss, if you understood his idea correctly, that you have to put each(?) of those statements into one(?) script. That would become a even bigger mess. After one month, probably nobody, even yourself can quickly figure out which script is for which sql statement any more.

I would suggest you to have a separate package, which you can call it SQLBuilder. If you want to impress your boss more, do it in OO-style.

The main function of this package is to build sql statement as instructed by you, and return the sql statement as a string. You should contain all the syntax details in this package, do it once forever.

Another benefit of this approach is that, it makes your code more portable. What I realized in the past is that, the sql syntax is actually slightly different from database to database, as they all support some sort of their own extension. If you want to port your script to a different database one day in the future, the sql syntax changes will be contained in this package, instead of spreaded everywhere.