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

Murray Cumming wrote:

This seems to add a function like this:

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.

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

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

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?


Murray Cumming
murrayc murrayc com

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