Re: [sqlite] Always call a value-quoting routine

On 7 May 2018 at 15:13, Scott Robison wrote: > On Sun, May 6, 2018 at 11:34 PM, Rowan Worth wrote: > > Its omission is interesting though. Does it indicate an incompetent > > attacker, or is companieshouse.gov.uk using some bespoke approach like > >

Re: [sqlite] Getting statement column data types on Android

https://www.sqlite.org/c3ref/column_blob.html int sqlite3_column_type(sqlite3_stmt*, int iCol); ? On Mon, May 7, 2018 at 4:28 PM, Bart Smissaert wrote: > Yes, thanks, that might be the best way, but it can get a bit complicated > with complex SQL. > > RBS > > > > On

Re: [sqlite] Fossil Delta Compression in SqLite

I am far from an expert in this field myself so I don't know whether including it in the text section of the binary would be enough, and the main issue for me is when clients of mine redistribute middleware in their turn as I mentioned in an earlier post. But either way, Richard already

Re: [sqlite] Getting statement column data types on Android

Yes, thanks, that might be the best way, but it can get a bit complicated with complex SQL. RBS On Tue, May 8, 2018 at 12:05 AM, Simon Slavin wrote: > On 7 May 2018, at 10:49pm, Bart Smissaert > wrote: > > > Using B4A for a SQLite database app

Re: [sqlite] Getting statement column data types on Android

On 7 May 2018, at 10:49pm, Bart Smissaert wrote: > Using B4A for a SQLite database app on an Android phone. > B4A doesn't have functions like sqlite3_column_decltype and > sqlite3_column_type > and this is causing some difficulty getting the column datatypes of a row >

[sqlite] Getting statement column data types on Android

Using B4A for a SQLite database app on an Android phone. B4A doesn't have functions like sqlite3_column_decltype and sqlite3_column_type and this is causing some difficulty getting the column datatypes of a row producing statement. If we have for example: create table Table1(ID Integer, Name

Re: [sqlite] Fossil Delta Compression in SqLite

On May 7, 2018, at 9:53 AM, Philip Bennefall wrote: > > It was merely an idea to possibly avoid some potential ambiguity regarding > public domain, which is a bit of a gray area in many places. So take the code under the explicit license, then. In my non-expert opinion,

Re: [sqlite] Fossil Delta Compression in SqLite

On 2018/05/07 5:53 PM, Philip Bennefall wrote: It was merely an idea to possibly avoid some potential ambiguity regarding public domain, which is a bit of a gray area in many places. Obviously not a requirement for anyone to do anything, it was but a friendly question. All good sir, the jibe

Re: [sqlite] Fossil Delta Compression in SqLite

It was merely an idea to possibly avoid some potential ambiguity regarding public domain, which is a bit of a gray area in many places. Obviously not a requirement for anyone to do anything, it was but a friendly question. Kind regards, Philip On 5/7/2018 5:44 PM, R Smith wrote: On

Re: [sqlite] Fossil Delta Compression in SqLite

On 2018/05/07 5:33 PM, Philip Bennefall wrote: Thanks very much for that information, Richard! :) I don't know if it would make any difference legally, but perhaps this could be made explicit in the comments? So it's not enough to get it free... the free giver has to now put some extra

Re: [sqlite] Fossil Delta Compression in SqLite

Thanks very much for that information, Richard! :) I don't know if it would make any difference legally, but perhaps this could be made explicit in the comments? Thanks again. Kind regards, Philip On 5/7/2018 5:22 PM, Richard Hipp wrote: You are welcomed to use the public-domain version of

Re: [sqlite] Fossil Delta Compression in SqLite

You are welcomed to use the public-domain version of the delta encoding routines found in the SQLite source tree for whatever purpose you want, without attribution. I am the sole author of that code, and I am a citizen of a country that allows people to disavow intellectual property claims, so it

Re: [sqlite] Fossil Delta Compression in SqLite

As far as I can judge, you need to include the entire license - or at least the majority of it - in the documentation (not just a single line). For an end user product that's fine, but I would rather not have to ask clients to do so if I am distributing middleware simply because of a component

Re: [sqlite] Always call a value-quoting routine

On 5/7/18, 2:14 AM, "sqlite-users on behalf of Scott Robison" wrote: It could just indicate someone with a sense of humor who crafted a name that looks like an injection attack for their company. Most

Re: [sqlite] Fossil Delta Compression in SqLite

On 5/6/18, 11:23 AM, "sqlite-users on behalf of Philip Bennefall" wrote: Only the requirement for attribution in binaries. That can be significant in certain use cases. One line of text in the documentation

Re: [sqlite] possible bug affecting 3.22 and 3.23 - load_extension()

I have checked in a change to address this on trunk. Meanwhile, your work-around is to include the ".so" suffix on the library name. xample: SELECT load_extension('mod_spatiallite.so'); On 5/6/18, a.furi...@lqt.it wrote: > it seems that some unexpected regression is

Re: [sqlite] Always call a value-quoting routine

On Sun, May 6, 2018 at 11:34 PM, Rowan Worth wrote: > Amusing -- but without the leading single-quote it would take intentional > effort for a programmer to detonate this payload. > > Its omission is interesting though. Does it indicate an incompetent > attacker, or is