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

[Dru <andru treshna com>]

Rodrigo Moya wrote:

> On Mon, 2004-10-11 at 09:48 +0200, Vivien Malerba wrote:
>  
>
> > On Mon, 11 Oct 2004 20:37:17 +1300, Dru <andru treshna com> wrote:
> >    
> >
> > > Vivien Malerba wrote:
> > >
> > >      
> > >
> > > > On Sun, 10 Oct 2004 13:43:05 +0000, Jeronimo Albi
> > > > <amenofisvii yahoo com ar> wrote:
> > > > [...]
> > > >
> > > >
> > > >        
> > > >
> > > > > 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.
> > > > >
> > > > >
> > > > >          
> > > > The problem with the structures built by the parser is that they are
> > > > very efficient for parsing a query, but not adapted to render a
> > > > structure as a SQL statement. I don't have this problem in libmergeant
> > > > since I never use that feature (the sql_statement structure is used to
> > > > create MgQuery objects and then discarded, and then the MgQuery is
> > > > responsible to do its own rendering taking into account the real
> > > > values for the parameters).
> > > >
> > > >
> > > >        
> > > Creating statements for insert/delete/update is pretty easy
> > > without using the sql parser. Its strength is pulling apart
> > > select statements so you know exactly whats been asked.
> > > Should anything be done for its future direction?
> > >
> > >      
> > As I said I exclusively use the SQL parser to parse a SQL string, not
> > to generate a string, and I think it should stay like that: the SQL
> > rendering should not be done by the parser.
> >
> >    
> well, we can still provide functions that can be used when no special
> SQL is needed. That is, some providers (XML for instance) will
> understand the same SQL that the SQL parser supports, so it makes sense
> to provide a _to_string function to get the string for that command.
>  
When i use the parser I pull the query apart, modify it, and
then put it back together again. The current version will
put back together anything it pulled apart. For the most part
i found strigifying the sql_statement only useful if i'm modifying
a query and want the new string version. If i am building
a query from stratch g_strdup_printf is more efficient.