Warning: just one man's opinion.
"Generative Programming" as a movement is similar to oh-so-many other movements in software engineering. Its proponents posit as a a universal solution to everyone's problems. The reality is that it's a tool in the toolbox, and nothing more. So is parsing. Each tool is good for something.
In the case you've brought up, the SQL generator would need metadata about a given database. How would it get the metadata? Probably by parsing either an XML description or a SQL description of the database. How does the database deal with the generated SQL? By parsing it. So you really can't have one without the other.
In another
thread, you bring this up again in as it relates to rule engines. And again, it all depends on how you look at it. A rule engine takes some description of a rule and compiles it (by parsing it) into an internal representation. Or, if you want to look at it differently, the rules are metadata, and the internal representation is generated by the rule engine. This internal representation is a procedural program of sorts (a FSM of some kind) while the rules themselves were declarative. It all depends on your point of view.
Where do the rules come from? A person might write them, or they may be generated from metadata. How does the generator get the metadata? Probably by parsing it from somewhere. And how does the generator get written? Someone has to write the rules by hand, study them, optimize them, generalize them, and then write the generator. This make sense if the rules for every application look the same, but of course, they often don't in reality. There's less commonality across applications than the GP folks want you to think.
A perhaps relevant situation from my experience: in the CAD/CAM world, much has been made in the last decade or two of the notion of Parametric Design. The idea is that you build a computer model of, say, a gear. The number of teeth, the diameter, the width of each tooth, and many other quantities are
parameters that aren't specified in the model. Part of the model can be commands to computer-controlled machines to actually create a gear based on parameters. You can create metadata-driven tools to generate simple GUIs to let people design their own gears. To manufacture a real gear, you just plug in the numbers, and copies of the precise gear you want start rolling off the assembly line. A telephone operator can do it. You can send all the engineers home.
This works great for ACME Gears Unlimited, which makes vast families of similar gears. It works badly, though, for Consolitated Random Objects, Inc, which will never make more than one kind of gear. You need new CAD models all the time. Are there commonalities among designs? Absolutely. Does generative programming help? Not a whole lot -- those engineers will be busy building CAD models by hand.
Note that both kinds of businesses are important: you go to ACME when you're mass-producing alarm clocks from COTS parts. You go to Consolidated when you're building a prototype space shuttle for NASA. Every business, every situation is different, and no metadata schema will ever be flexible to cover the entire range of human experience.
Apparently, the cover alone is worth it.
