Re: [gnome-db] Studying the posibility to add parametrized statements

[Dru <andru treshna com>]

Jeronimo Albi wrote:

>    1. I should use sql_parse() to create an #sql_statement.
>  
>
> I'll explain what i undestood about your code in libgda/libsql:

Yes

>    2. Inside #sql_statement record i have a field named "statement" to
>       get the structures #sql_select_statement, #sql_insert_statement,
>       and so on, depending on the statement type.
>  
Yip the pointer type will be sql_select_statement if its an select.
The type in statement indicates its type.

>    3. Inside some of them i have a #GList of #sql_field items, and
>       inside each item a #param_spec containing parameters info, that
>       is what i'm looking for :-).
>  
Have a look at the stringify code to see how the fields are built.
Its a little complx because a field can be a constant, variable, fucntion,
subselect etc.

>    4. sql_stringify() shuld return a string containing the parsed
>       statement
>  
Yes. There were a few bugs in it with earlier versions but I havn't
found any problem the current CVS HEAD. If there is let me or Vivien know.

>  How should i replace parameters with a token to be interpreted by 
> a database engine as parameter. For example in Firebird:
>
>    a. Original statement:
>           SELECT name FROM table WHERE name=## [:name="User name"]
>    b. Parsed statement shuld be:
>           SELECT name FROM table WHERE name=?
>
> where "?" is interpreted as parameter.
> 		
>  Does #sql_update_statement and #sql_delete_statement structures 
> support parameters ?
>  
They have a WHERE list though not much beyond that so if you get real 
complex on your inserts, deletes etc it may complain. Not a huge amount 
of work has been done on inserts, deletes, updates
compared with SELECTs. I often generate inserts or updates using sql 
parser and dont use it to parse them so much as create the insert and 
delete statements for me.

I wrote a function a month or so ago to get the where component from a 
statement which
may help you. sql_statement_get_wherejoin_components() its in sql_parser.c
I found it easier to write functions to extract the data needed in 
sql_parser
than dealing with the structures over and over again in the code.
Previously when checking for parameters in sql statemnets i've just 
pre-parsed
it before giving it to the sql parser. I think in the long run it would 
be a lot more
useful to do the checking in the libsql parser to save double work by 
bonddb/papyrus/libgda and libmeargant. It'll need callbacks though to 
get the data.

the sql_field_item could be changed to include information about 
parameter and added into
the union as just a new type of sql_field_type. And the bison code needs 
to be able to read ##'s and correctly parse what text is next.