Re: [sqlite] 3.5.7 & TCL: "undefined symbol: sqlite3StrICmp"
On Fri, Apr 04, 2008 at 01:43:24PM -0700, Steven Fisher wrote:
> On 04-Apr-2008, at 1:17 PM, Nicolas Williams wrote:
> > Sure there is:
> >
> >const char *sqlite3_column_decltype(sqlite3_stmt*,int);
> >int sqlite3_column_type(sqlite3_stmt*, int iCol);
>
> This would be useful but, again, that's not at all what I want. I'm
> looking for column NAMES, not contents.
const char *sqlite3_column_name(sqlite3_stmt*, int N);
const void *sqlite3_column_name16(sqlite3_stmt*, int N);
> Maybe it'd be better to explain this with psuedo code.
>
> This is what I want to do:
>
>sqlite3_prepare_v2( db, "SELECT ColumnA,ColumnB FROM ATable;", -1,
> , );
>int column_a_idx = sqlite3_column_index( stmt, "ColumnA" );
>int column_b_idx = sqlite3_column_index( stmt, "ColumnB" );
>while ( sqlite3_step( db ) == SQLITE_ROW ) {
> sqlite3_column_text( stmt, column_a_idx, avalue );
> sqlite3_column_text( stmt, column_b_idx, bvalue );
>}
>sqlite3_fianlize( stmt );
You can have multiple columns with the same name:
sqlite> create table foo(a,b);
sqlite> insert into foo values (1, 2);
sqlite> .header on
sqlite> select a as c, b as c from foo;
c|c
1|2
sqlite>
So sqlite3_column_index(stmt, "ColumnA") isn't likely to be what you
really want. sqlite3_column_name() seems much more appropriate.
> I'm avoiding hard an expectation here that column a is in position 0,
> and column b in position 1. This doesn't matter for such a simple
> query, but for larger queries future proofing the code from changes to
> queries is just good practice.
>
> This code won't run, though, because sqlite3_column_index doesn't
> exist. I need to write my own. That means I need to replace
> sqlite3_column_index with find_column, which is defined something like
> this:
>
> int find_column( sqlite3_stmt * stmt, const char * name )
> {
>int count = sqlite3_column_count( stmt );
>for ( int i = 0; i < count; i++ ) {
> const char * column = sqlite3_column_name( stmt, i );
> if ( stricmp( column, name ) == 0 )
>return i;
>}
>return -1;
> }
Right, except for the thing about multiple columns with the same name
being OK.
> There's two problems here:
> 1. I need to define something to find the column at all. There's a way
> to find binding indexes by name, so why not columns? I understand the
> need to avoid code bloat, but surely a way to future proof code by not
> having to hard-coding column positions is worth the size delta.
See above.
> 2. I need to use stricmp for comparing column names. I'd rather use
> the same comparison that sqlite3 uses for comparing column NAMES.
Why can't you use strcasecmp()?
IMO a SQLite-specific version of strcasecmp() is only really valuable if
it can deal with user-defined collations. Otherwise what's the point?
You already have straight strcasecmp() implementations elsewhere (even
ones aware of UTF-8 and UTF-16).
Nico
--
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.5.7 & TCL: "undefined symbol: sqlite3StrICmp"
On 04-Apr-2008, at 1:17 PM, Nicolas Williams wrote:
> On Fri, Apr 04, 2008 at 01:06:58PM -0700, Steven Fisher wrote:
>>> It's not necessarily the same as strcasecmp(). You can have per-
>>> column collations.
>>
>> Column names, not column contents. :) I don't like to have my C code
>> rely on the order of columns from a query. You can avoid depending on
>> parameter ordering with sqlite3_bind_parameter_index, but there
>> doesn't seem to be an equivalent for result columns.
>
> Sure there is:
>
>const char *sqlite3_column_decltype(sqlite3_stmt*,int);
>int sqlite3_column_type(sqlite3_stmt*, int iCol);
This would be useful but, again, that's not at all what I want. I'm
looking for column NAMES, not contents.
Maybe it'd be better to explain this with psuedo code.
This is what I want to do:
sqlite3_prepare_v2( db, "SELECT ColumnA,ColumnB FROM ATable;", -1,
, );
int column_a_idx = sqlite3_column_index( stmt, "ColumnA" );
int column_b_idx = sqlite3_column_index( stmt, "ColumnB" );
while ( sqlite3_step( db ) == SQLITE_ROW ) {
sqlite3_column_text( stmt, column_a_idx, avalue );
sqlite3_column_text( stmt, column_b_idx, bvalue );
}
sqlite3_fianlize( stmt );
I'm avoiding hard an expectation here that column a is in position 0,
and column b in position 1. This doesn't matter for such a simple
query, but for larger queries future proofing the code from changes to
queries is just good practice.
This code won't run, though, because sqlite3_column_index doesn't
exist. I need to write my own. That means I need to replace
sqlite3_column_index with find_column, which is defined something like
this:
int find_column( sqlite3_stmt * stmt, const char * name )
{
int count = sqlite3_column_count( stmt );
for ( int i = 0; i < count; i++ ) {
const char * column = sqlite3_column_name( stmt, i );
if ( stricmp( column, name ) == 0 )
return i;
}
return -1;
}
There's two problems here:
1. I need to define something to find the column at all. There's a way
to find binding indexes by name, so why not columns? I understand the
need to avoid code bloat, but surely a way to future proof code by not
having to hard-coding column positions is worth the size delta.
2. I need to use stricmp for comparing column names. I'd rather use
the same comparison that sqlite3 uses for comparing column NAMES.
The first problem could be fixed by adding sqlite3_column_index, the
second by adding sqlite3_stricmp. The first would (probably?) increase
the size of sqlite3 slightly, the second would only make an internal
function publicly available.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.5.7 & TCL: "undefined symbol: sqlite3StrICmp"
On Fri, Apr 04, 2008 at 01:06:58PM -0700, Steven Fisher wrote: > > It's not necessarily the same as strcasecmp(). You can have per- > > column collations. > > Column names, not column contents. :) I don't like to have my C code > rely on the order of columns from a query. You can avoid depending on > parameter ordering with sqlite3_bind_parameter_index, but there > doesn't seem to be an equivalent for result columns. Sure there is: const char *sqlite3_column_decltype(sqlite3_stmt*,int); int sqlite3_column_type(sqlite3_stmt*, int iCol); Now, you have to parse the decltype to get the collation. In any case, sqlite3StrICmp() doesn't take a collation name. So sqlite3StrICmp() would not make a good public interface. I think something like: const char *sqlite3_column_text_collation(sqlite3_stmt*, int iCol); int sqlite3_textcmp(const char *collation, const char *s1, const char *s2); int sqlite3_textcmp16(const char *collation, const char *s1, const char *s2); would be better. I think I could volunteer to write something like that (I can do copyright assignment and all that) if the project would welcome it. Nico -- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.5.7 & TCL: "undefined symbol: sqlite3StrICmp"
On 04-Apr-2008, at 12:54 PM, Nicolas Williams wrote: > On Fri, Apr 04, 2008 at 12:48:05PM -0700, Steven Fisher wrote: >> On 03-Apr-2008, at 11:22 PM, Matthew L. Creech wrote: >>> We need to either rename it so >>> that it's part of the library's exported API, or do something >>> different in tclsqlite.c. >> >> I would really like to have a few of sqlite3's internal functions >> available to client applications in a straightforward manner. >> sqlite3StrICmp is the top one on my list, though I could see >> sqlite3StrNICmp and sqlite3IsNumber being useful as well. >> >> When comparing column names in my code, for instance, it makes a lot >> of sense to be able to use the same code for comparison that sqlite3 >> uses. Sure, it's probably the same as stricmp/strcasecmp, but will it >> always be so? Probably, but it'd be more future-proof just to use the >> same code. > > It's not necessarily the same as strcasecmp(). You can have per- > column > collations. Column names, not column contents. :) I don't like to have my C code rely on the order of columns from a query. You can avoid depending on parameter ordering with sqlite3_bind_parameter_index, but there doesn't seem to be an equivalent for result columns. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.5.7 & TCL: "undefined symbol: sqlite3StrICmp"
On Fri, Apr 04, 2008 at 12:48:05PM -0700, Steven Fisher wrote: > On 03-Apr-2008, at 11:22 PM, Matthew L. Creech wrote: > > We need to either rename it so > > that it's part of the library's exported API, or do something > > different in tclsqlite.c. > > I would really like to have a few of sqlite3's internal functions > available to client applications in a straightforward manner. > sqlite3StrICmp is the top one on my list, though I could see > sqlite3StrNICmp and sqlite3IsNumber being useful as well. > > When comparing column names in my code, for instance, it makes a lot > of sense to be able to use the same code for comparison that sqlite3 > uses. Sure, it's probably the same as stricmp/strcasecmp, but will it > always be so? Probably, but it'd be more future-proof just to use the > same code. It's not necessarily the same as strcasecmp(). You can have per-column collations. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.5.7 & TCL: "undefined symbol: sqlite3StrICmp"
On 03-Apr-2008, at 11:22 PM, Matthew L. Creech wrote: > We need to either rename it so > that it's part of the library's exported API, or do something > different in tclsqlite.c. I would really like to have a few of sqlite3's internal functions available to client applications in a straightforward manner. sqlite3StrICmp is the top one on my list, though I could see sqlite3StrNICmp and sqlite3IsNumber being useful as well. When comparing column names in my code, for instance, it makes a lot of sense to be able to use the same code for comparison that sqlite3 uses. Sure, it's probably the same as stricmp/strcasecmp, but will it always be so? Probably, but it'd be more future-proof just to use the same code. I include sqliteInt.h in a small c file just sqlite3StrICmp, in fact. It would be nice not to have to do this. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.5.7 & TCL: "undefined symbol: sqlite3StrICmp"
On Fri, Apr 04, 2008 at 08:48:53AM -0400, D. Richard Hipp wrote: > The way we build the TCL interface that is on the download > page is that the TCL interface code becomes part of the > amalgamation and the whole thing is compiled as a single > translation unit. I cannot imagine why anyone would want > to do it differently. I can, since I wanted to do it differently when integrating SQLite3 into Solaris. There's several reasons: 1a) Shared libraries are a way of life in Solaris (and other OSes), and avoiding object code duplication is, specifically, a goal. 1b) Patches to libsqlite3 need only patch that, not also libtclsqlite3, and even if libtclsqlite3 needs patching, the lack of object code duplication will make the patches smaller (though perhaps also less compressible). 2) In the very unlikely (but not infeasible) event that one should have an application that uses Tcl and C interfaces to access the same SQLite DB then all hell will break loose if libtclsqlite has its own internal copy of libsqlite -- there will be two distinct copies of libsqlite object code in one process accessing the same DB. 3) Bindings of SQLite3 for other languages don't have the same luxury of calling private libsqlite functions. On principle neither should the TCL bindings. If nothing else it will help keep the libtclsqlite code clean and separable. (2) is not so farfetched. I used to maintain a proprietary (now open source) product called UName*It that did just this, though with a different, also proprietary DB. The current maintainers have expressed a desire to use SQLite instead, which would result in (2) unless they did even more surgery to UName*It than they thought they'd have to. >But just yesterday I had a chat conversation > with an engineer at Novell/SuSE and he could not understand > why anybody would want to do it my way - since that would > me there were two complete copies of the SQLite library on > disk. Different strokes for different folks, I guess... We have that view as well. It's quite prevalent. The problem is that as more operating systems bundle SQLite your notion of embeddable gets tested. Does embeddable mean that the object code is statically linked into the application? Or that the DB isn't a networked DB? IMO: the latter. I strongly advise that libtclsqlite3 should have no dependencies on private interfaces in libsqlite3. Nico -- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.5.7 & TCL: "undefined symbol: sqlite3StrICmp"
On Fri, Apr 04, 2008 at 08:48:53AM -0400, D. Richard Hipp wrote: > This has never been a problem for the prebuilt binaries on > the website. Neither this wasn't any problem for earlier sources (including 3.5.6). > Anyway, you can fix the problem by either using the > precompiled binaries, or downloading the latest from > CVS. Thanks, the patch seems to be working. Binaries are good solution for Windows (and perhaps for Mac too) - but for Linux rarely it is the case. You know: "dependencies" - especially, when somebody prefers "stable" releases, thus having older libraries, than the ones used for pre-built binaries. -- pozdrawiam / regards Zbigniew Baniewski ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.5.7 & TCL: "undefined symbol: sqlite3StrICmp"
On Apr 3, 2008, at 10:46 PM, Zbigniew Baniewski wrote: > I'm sorry to confirm the problem described at http://tinyurl.com/ > 29wc8x > > #v+ > $ tclsh8.5 > % package require sqlite3 > couldn't load file "/usr/lib/sqlite3/libtclsqlite3.so.0": > /usr/lib/sqlite3/libtclsqlite3.so.0: undefined symbol: sqlite3StrICmp > #v- > > Does there exist any cure? > http://www.sqlite.org/cvstrac/chngview?cn=4965 This has never been a problem for the prebuilt binaries on the website. Somebody must have built their own binary that separates the SQLite library from the TCL library and puts them in two separate shared libraries. (Perhaps the configure/make script does this.) The way we build the TCL interface that is on the download page is that the TCL interface code becomes part of the amalgamation and the whole thing is compiled as a single translation unit. I cannot imagine why anyone would want to do it differently. But just yesterday I had a chat conversation with an engineer at Novell/SuSE and he could not understand why anybody would want to do it my way - since that would me there were two complete copies of the SQLite library on disk. Different strokes for different folks, I guess... Anyway, you can fix the problem by either using the precompiled binaries, or downloading the latest from CVS. D. Richard Hipp [EMAIL PROTECTED] ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.5.7 & TCL: "undefined symbol: sqlite3StrICmp"
On Thu, Apr 3, 2008 at 10:46 PM, Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: > I'm sorry to confirm the problem described at http://tinyurl.com/29wc8x > > #v+ > $ tclsh8.5 > % package require sqlite3 > couldn't load file "/usr/lib/sqlite3/libtclsqlite3.so.0": > /usr/lib/sqlite3/libtclsqlite3.so.0: undefined symbol: sqlite3StrICmp > #v- > > Does there exist any cure? Nothing simple, unfortunately. It looks like that function is built with static linkage as part of the amalgamation, so it's inaccessible to modules outside of libsqlite3.so. We need to either rename it so that it's part of the library's exported API, or do something different in tclsqlite.c. It's the only internal function this is a problem with, by the way - you can check "nm -D libtclsqlite3.so" for all 'U' (undefined) symbols. -- Matthew L. Creech ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.5.7 & TCL: "undefined symbol: sqlite3StrICmp"
On Thu, Apr 03, 2008 at 09:54:15PM -0500, John Stanton wrote: > Install TCL Another one? What for? -- pozdrawiam / regards Zbigniew Baniewski ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.5.7 & TCL: "undefined symbol: sqlite3StrICmp"
Zbigniew Baniewski wrote: > I'm sorry to confirm the problem described at http://tinyurl.com/29wc8x > > #v+ > $ tclsh8.5 > % package require sqlite3 > couldn't load file "/usr/lib/sqlite3/libtclsqlite3.so.0": > /usr/lib/sqlite3/libtclsqlite3.so.0: undefined symbol: sqlite3StrICmp > #v- > > Does there exist any cure? Install TCL ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] 3.5.7 & TCL: "undefined symbol: sqlite3StrICmp"
I'm sorry to confirm the problem described at http://tinyurl.com/29wc8x #v+ $ tclsh8.5 % package require sqlite3 couldn't load file "/usr/lib/sqlite3/libtclsqlite3.so.0": /usr/lib/sqlite3/libtclsqlite3.so.0: undefined symbol: sqlite3StrICmp #v- Does there exist any cure? -- pozdrawiam / regards Zbigniew Baniewski ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
