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

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:


   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
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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]