Re: [gnome-db] libgda escape_value() and schema retreival

[Alan Knowles <alan akbkhome com>]

Murray Cumming wrote:

> > > This seems to add a function like this:
> > >
> > > gboolean
> > > gda_connection_escape_string (GdaConnection *cnc,
> > > 			      gchar *from,
> > > 			      const gchar *to,
> > > 			      unsigned long length)
> > >      
> > >
> > > 1. Why do we need to provide the length of the "from" string? Surely, all
> > > strings in libgda are null-terminated?
> > >
> > >
> > >      
> > Sorry dont know libgda that well to comment..
> >    
>
> It looks wrong. Rodrigo?
>
>  
>
> > > 2. It seems to convert from "to" to "from". Isn't that a bit backwards?
> > >      
> > Actually, it was a pretty straight copy from the original mysql_/pgsql_
> > functions that did the same thing.
> >    
>
> I doubt that - could you show us the function signature for those
> functions, please? Maybe someone just put the const in the wrong place.
Spot on - the const is on the from.

unsigned long STDCALL mysql_real_escape_string(MYSQL *mysql,
                                              char *to,const char *from,
                                              unsigned long length);

>  
>
> > - the only justification for keeping
> > that standard was probably that anyone who's familar with the API's
> > would pick up libgda a minute bit faster..
> >
> >    
> >
> > > 3. Is this just for creating SQL-representations of text values? Surely
> > > it's more useful to have a funciton to create a SQL representation of a
> > > GValue, whatever type that GValue has.
> > >
> > >
> > >      
> > I agree, That would be better, In reality though, it's only strings
> > AFAIK that need escaping, and may be locale specific on the database
> > (eg. BIG5 in a mysql db, has to watch out what it quotes..) so if it was
> > implemented as a Gda_connection_value_to_Sql(Gda_connection,
> > Gda_value,gchar) - only when the gda_value was a string, would the
> > function be called.
> >    
>
> Well,
> 3.1: I'd like this function to add the quotes (I consider that part of
> "escaping"), so it wouldn't just be strings that had quotes.
>  
This sounds fair - the API I wrote originally just did escaping only, 
I've yet to see a situatation where it couldnt be made to work with the 
quotes as well..

> 3.2: The function would need to create a text representation for numbers,
> dates, and times, so it would do something. This would remove lots of
> duplicated code in applications.
>  

> Also, it should create the text representation in the canonical locale (I
> believe that the SQL specification says that it should be the C locale,
> even if the database backend chooses to store them in some other locale).
> Otherwise, the application has to do the work of creating an appropriate
> C-locale text representation for times, dates and numbers. That's not
> always easy.
>
>  
>
> > > 4. Does this add the quotes, or do you need a big switch/case (switching
> > > on the field type) block in the app for that?
> > >
> > >
> > >      
> > actually, only a few types varchar/char/text need escaping (which are
> > represented as a single type in gda? AFAIK), so it's not that huge a
> > switch/case.
> >    
>
> 4. was not about escaping of text fields, but about quotes. Not just text
> fields need quotes, or text representations, in SQL. For instance, I think
> dates needs quotes, and they need to be a text representation in the C
> locale.
>
>  
yeah - missed that.. - basically I went with the blanket, if it needs 
escaping, then it also uses quote (so dates etc. are also escaped). 
however I dont deal with dates as a native type, they are just strings 
in the API I wrote.
+100 on just making a function to convert GdaValue's into SQL strings.
I guess the only question is, whether it should use the native backend 
escaping methods?

Regards
Alan

> Murray Cumming
> murrayc murrayc com
> www.murrayc.com
> www.openismus.com
>