Re: [gnome-db] Per-table meta-data with capital letters in the table name?





2009/7/1 Murray Cumming <murrayc murrayc com>


>  and the
> rule I chose is the following: the identifier as reported by the meta
> store
> can _always_ be used as is,

Maybe it can be used "as is" for other parts of the metadata API, and
maybe for building SQL statements. But it can't be used as is to show a
table name to a user.

Just test if the 1st char is a double quote and if so then call gda_sql_identifier_remove_quotes(). 
 
And this quotes/no-quotes/lowercasing dance is awful when trying to give
something to the meta data api that's based on user input. I feel it
makes my app's behaviour very unstable.

If you have use input, then use gda_sql_identifier_needs_quotes()/gda_sql_identifier_add_quotes().

You won't be able to have at the same time a database abstraction layer and use user input without any validation. For example if you the user has a MyTable table name, then to use this table you _will_ at some point have to check if you need quotes or not yourself. Libgda offers you some functions to do it and gives you some "normalized" representation and behaviour. Of course if you always quote SQL identifiers you don't care, but Libgda can't assume its users want to systematically quote SQL identifiers.

I shouldn't need to do
some_api_do_something( some_api_transform_the_parameter_so_it_works(thing) );

If a function sometimes wants quotes around an input string then it
should put quotes around it. Likewise with the lowercasing.

You can't reliably determine what the user had in mind as SQL has never standardized on case sensitiveness of SQL identifiers (this is AKAIK the only language where this is the case). For example a user may enter (using here asterixes instead of doule quotes to avoid confusion) *mytable*, or *MYTABLE* or *Mytable* to represent the same object because he has his own habits (Postgres or Oracle background, or prefering readability).

Anyway, I've committed to git master and LIBGDA_4.0 branches corrections with documentation which explain the design choices that were made.

Regards,

Vivien


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