Hi, On Thu, Mar 16, 2006 at 04:44:45PM +0100, "A. Pagaltzis" wrote: > * Luke Ross <[EMAIL PROTECTED]> [2006-03-16 16:25]: > >I'm writing a module that, using the magic of source filters, > >allows you to write SQL in a database-independent perl-ish > >notation. > > I wonder why this should be a filter. Based on the example you've > given, there's no reason this pseudocode couldn't just be passed > as a string.
I've probably approached this the wrong way, but I wanted to keep control over variable interpolation. Given the expression "table->column = $value" the expression is compiled to SQL "table.column = ?" at compile-time, and at run-time $value is passed to DBI as a bind parameter. That way, you don't need to rebuild the query at run-time or have the calling program protect quotes in $value. On the names front, DBIx::SQL::Perlish seems like a reasonable starting point, but I'm inclined to opt for DBIx::SQL::PerlExpression or DBIx::SQL::PerlishExpression. The syntax used in, say, DBIx::Abstract is perfectly valid perl, but uses data-structures to build the where clause rather than making it a single expression. Although the name is then getting a bit of a mouthful... Regards, Luke
