I think I do understand, if it's the same thing that I initially
expected when I read that SQL statements are SQL::Statement objects.
SQL::Statement can parse and interpret SQL statements.
It would be useful to expose an object model for parsed statements
allowing the user to read, modify, and create such statements
without having to go through the asinine duty of getting the
surface syntax for those statements right.
Completely hypothetical example:
use SQL::Expression::ColumnValued qw(avg count first distinct column);
use SQL::Expression::TableValued qw(table, natural_join);
my $stmt = new SQL::Statement::Select(
{
yield =>
[ avg(column('salary')), count(distinct(column('firstname'))),
column('lastname') ],
from =>
[ natural_join(table('employee'), table('salry')) ]
group_by =>
[ column('lastname') ]
});
$stmt->to_string # is:
# SELECT AVG(salary), COUNT(DISTINCT(firstname)), lastname
# FROM employee NATURAL JOIN salry
# GROUP BY lastname
$stmt->from->join[1]->column = 'salary';
push($stmt->yield, first(column('firstname')));
$stmt->to_string # is now:
# SELECT AVG(salary), COUNT(DISTINCT(firstname)), lastname,
# FIRST (firstname)
# FROM employee NATURAL JOIN salary
# GROUP BY lastname
$stmt->execute()
This would get rid of the need to properly escape arbitrary table
and column names, and it might also perform sophisticated syntax
checking and validity checking against a given schema.
It's like prepare() but taking the idea to another level.
It's not all that useful, however, to have this in SQL::Statement,
because it would only work for those DBI backends that use it.
What I really want is something like this as a generic,
backend-independent interface to SQL, and that is not at all
what SQL::Statement, or DBI for that matter, tries to provide.
Some other DBI-based modules do take some steps in that direction.
--
Reinier Post
