Re: SQL::Statement parsing

John Cougar wrote:

IMHO, the API would be neater is it contained "parse_ok()" method - or
something similar - to provide an explicit test for successful parsing,
without having to enquire against errstr() as a (almost) side-effect.


I think the best thing is for me to follow DBI and have an err() method which returns true if an error has occurred, e.g.

my_error_handler( $stmt->errstr ) if $stmt->err;

In fact, I should probably allow users to pass an error-handling coderef to the parser.

On the other hand, why do you (as, indeed, does PostgreSQL) enforce the use
of the 'AS' keyword in column aliasing? Just a question, AS is optional in
SQL'92.


Hmm, darn, I'm inconsistent - the AS is optional on table aliases but required on column aliases. I'll add that to the to-do list, thanks.

I will
contributed patches as requested ... chat to you offline about this, dude!


Thanks much!

PS> On the Structure.pod, it says users should instantiate a parser and pass
the instance variable into the Statement constructor as an argument. In your
reply, you just created Statement->new($sql). I know that this works, but
what is the default dialect?


AnyData.

--
Jeff
.