On Monday, December 10, 2001, at 10:30 AM, Wilson, Doug wrote:
> >> From: Terrence Brannon [mailto:[EMAIL PROTECTED]] >> >> On Monday, December 10, 2001, at 09:16 AM, Jeff Zucker wrote: >> >>> Terrence Brannon wrote: >>>> >>>> The following SQL is not parseable by SQL::Statement: >>>> >>>> INSERT >>>> INTO thot_log (thot_fk,thot_type_fk,thot_temporality_fk,date) >>>> VALUES (?,?,?,CURRENT_TIMESTAMP) >> >> What I have is a program which reads a SQL statement from a file. >> It parses it with SQL::Statement, then it prepares this >> statement, then does an execute against it with @ARGV. I tried >> your quoting suggestion. In fact, I put the following 3 different >> things in the file: >> > > Prepares it and executes it against what database? If its > Postgres, then > Postgres should be parsing it, not SQL::Statement. CURRENT_TIMESTAMP is if you looked at sub SQL::Catalog::test and the associated commentary I made, the answer to this would be clear: the above-mentioned subroutine parses the statement with SQL::Statement so that it can store statistics about the query. Then it prepares and executes it via a routine which returns a valid $dbh > You can't expect SQL::Statement to handle every > special thing that every database might include in its > featureset/syntax. > Is Jeff redoing SQL::Statement with Parse::RecDescent? If so, we would conceivably subclass it with SQL::Statement::Postgres and I could add the appropriate new grammar items as I needed them.
