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

[Rodrigo Moya <rodrigo gnome-db org>]

On Wed, 2004-08-18 at 17:56 +0800, Alan Knowles wrote:
> 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?
> 
I guess so, at least for strings, dates, and other things. We probably
want the function to be value_to_string instead of escape_value ?
-- 
Rodrigo Moya <rodrigo gnome-db org>