Re: [gnome-db] refactoring completed

[Andrew Hill <andru treshna com>]

Rodrigo Moya wrote:

> On Mon, 2002-04-29 at 13:11, Andrew Hill wrote:
>
> > > > So Gonzalo was thinking on using a GScanner-based parser, which will
> > > > allow us to know exactly where the syntax error is, thus being more
> > > > powerful for our needs.
> > > 	Well, the flex/bison parser can tell where the error is and we
> > > 	can send a error to the caller. Also, if XQL does not check the
> > > 	syntax of the query, this check can be done converting it to
> > > 	SQL.
> > >
> > > 	The question is: do we want to be able to report an SQL syntax
> > > 	error before sending the query to the backend?
> > >
> > > 		* yes: then we need a bison/flex parser. As I said
> > > 		above, we can start using Andrew's and complete it to
> > > 		support SQL99.
> > >
> > > 		* no: we can do it with a lexer and some glue.
> > Do you want a seperate library for it?  at the moment its a seperate module
> > in my code but still in the makefile.
> I think we should just have a GdaSqlParser object in libgda. There's no
> need for a separated library, IMO.
I need to keep naming conventions standard between 2 different projects 
(ie it would
be called dbsqlparser under my naming conventions or GdaSqlParser under 
yours).
This is going to make things a bit messy, i dont mind making a serpate 
library if it is going to help keep it tidy.  
Naming convention is a bit confused between sql, dbsqlparse and 
sqlparser at the moment for
the module (written in hurry, was done seperatly so wasn't too important 
for consitentices). And i havn't used GObject, also glib isn't used a 
lot, except for lists
and string management.  I'll change things like variable types and 
memory allocation
to glib functions.

Code example:

Sql_comp *
sql_comp_build (Sql_comp_op op, char *left, char *right)
       {
       Sql_comp *retval;

       retval = malloc (sizeof (*retval));
       if (!retval)
           {
           errormsg ("Out of memory");
           return NULL;
           }

       retval->op = op;
       retval->left = left;
       retval->right = right;

       return retval;
       }

Oh yeah and it uses a debugging module i wrote but its real small and 
uses just stdio.
I'm going to have to add a memory management module (on todo list) as memory
management under bison is a bitch in knowing when exactly its safe to 
free a variable
and when its not.  

So if you cool with this style of coding i'll proceed. Its on my cvs 
server at the
moment, i'll give you a tar/gz when i get something working.
Hit me with feature requests early.

> > i normally use
> > module_file_functionname(...);
> > GLib variable names are used.
> >
> > Oh and someone else (Jean-Michel) asked about database specific sql 
> > commands.
> > Yeah I find at the moment using custom functions etc also chocks the SQL 
> > parser
> > so i jsut told my code to try anyway at the query if it fails the sql 
> > parser.  Cuase
> > it often did on those nasty sql statements.  And mark it that this sql 
> > isn't supported
> > by the parser.
> I think for the time being we are safe in only supporting standard SQL.
>
> > Anyway I'll be writing hte code over next 3 weeks, to get it up to 
> > scratch.  I only
> > SQL92 but if your familiar with lex your welcome to add in more.  
> cool! Having the SQL parser will allow us to add a lot of new features
> to libgda/libgnomedb/gnome-db, so, please, just tell us how many beers
> you need until you finish the parser, and we'll send them to you :-)
>
> cheers
lo. I think i code better under the influence of alchole, or so i 
thought last
friday.  though dont try and read the cvs log entries for that night, 
they become
quite unreadable by the end of it.  Anyway I'll start asking for some 
features
in gnome-db.