Re: [sqlite] New draft document on the new pointer-passing interfaces

On 7/24/17, petern wrote: > > Are sqlite3_result_subtype() and sqlite3_value_subtype() being deprecated > in light of the duplicate functionality? > No. The subtype() interfaces were originally created for completely unrelated purposes (specifically to identify

Re: [sqlite] New draft document on the new pointer-passing interfaces

Minor typo's and grammo's: 2.1) suppose -> supposed For example, the first argument to the snippet() function is suppose to be a special column space instead of the fts3cursor object it was suppose to be operating on 2.2) forge pointer -> forge a pointer forge pointer without the help of

Re: [sqlite] New draft document on the new pointer-passing interfaces

What about imposing some structure on the pointer type strings that uses a guaranteed unique substring, for example “org.sqlite.fts3.snippet”, to ensure there wouldn’t be accidental conflicts? On 7/24/17, 6:54 AM, "sqlite-users on behalf of Richard Hipp"

Re: [sqlite] New draft document on the new pointer-passing interfaces

On Mon, Jul 24, 2017 at 1:54 PM, Richard Hipp wrote: > https://www.sqlite.org/draft/bindptr.html Thanks. Very helpful. Still unsure whether not having a destructor D for pointer P is a good thing though. The text explicitly says the pointer is "destroyed" when not flowing

Re: [sqlite] New draft document on the new pointer-passing interfaces

Naming conventions (if strictly adhered to) are moderately good at avoiding conflicts, but take the guesswork out of "faking a pointer". It also assumes that pointers for "whatever" are interchangeable between different queries in a process, i.e. passing a "whatever" pointer from statement A to

Re: [sqlite] New draft document on the new pointer-passing interfaces

If you’re concerned about people faking pointers, you could always go with something like “org.sqlite.fts3.01Yzg5x.snippet”. But given this design, you need to have already injected a C extension to even access the pointers, so I’m not sure what the issue is. On 7/24/17, 9:19 AM, "sqlite-users

Re: [sqlite] rowid as foreign key

> Le 24 juil. 2017 à 20:58, Roman Fleysher a > écrit : > > Dear SQLiters, > > Is it possible to link two tables using rowid, the implicit column? I tried > and it did not work, so I presume the answer to my question is "no". Hello Roman, The answer is yes.

Re: [sqlite] rowid as foreign key

I am sorry, I did not ask the question correctly. I omitted "... link two tables, using foreign key...". I now see last sentence on http://sqlite.org/lang_createtable.html which states that it is not possible. Roman From: sqlite-users

[sqlite] rowid as foreign key

Dear SQLiters, Is it possible to link two tables using rowid, the implicit column? I tried and it did not work, so I presume the answer to my question is "no". Thank you, Roman ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] New draft document on the new pointer-passing interfaces

Gwendal. Yes. You've missed something. My application is working code not a hypothetical feature request. BLOB application object pointer lifetime presently works precisely as I've described and without memory leak. My point (and Dominique's point) was that this proposal as it stands isn't a

Re: [sqlite] New draft document on the new pointer-passing interfaces

Your proposal does not walk through the alternative of sticking with subtypes to add non-persistent sqlite3_bind_subtype() and corresponding sqlite3_column_subtype() methods. With a few extra lines and some imagination can't this more straightforward alternative be combined with the existing BLOB

Re: [sqlite] rowid as foreign key

Yes, but to use the rowid or a table in a foreign key declaration you need to specify it explicitly in the table definition declaring it as the INTEGER PRIMARY KEY. (and exactly INTEGER PRIMARY KEY, although you can also add the AUTOINCREMENT keyword if you need to ensure unique values for

Re: [sqlite] New draft document on the new pointer-passing interfaces

On 7/24/17, 3:50 PM, "sqlite-users on behalf of petern" wrote: > BTW, if the hypothetical attacker has a copy of the application, aren't the > constant space pointer access keys' string addresses all there

Re: [sqlite] New draft document on the new pointer-passing interfaces

> Le 24 juil. 2017 à 19:02, petern a écrit : > > To those posting low information congratulatory notes on this thread, you'd > better hold off on popping those champagne corks. The current API already > contains irreversible additions to solve this problem that

Re: [sqlite] New draft document on the new pointer-passing interfaces

Great. But, if this is an ultimate replacement for BLOB'ed pointers, these new pseudo-null pointers must support SQLITE_STATIC and destructor function pointer lifetime disposition for those migrating their code. Why can't the producer destructor disposition be preserved within a chain of

Re: [sqlite] New draft document on the new pointer-passing interfaces

> Le 24 juil. 2017 à 19:02, petern a écrit : > > Great. But, if this is an ultimate replacement for BLOB'ed pointers, these > new pseudo-null pointers must support SQLITE_STATIC and destructor function > pointer lifetime disposition for those migrating their code.

Re: [sqlite] New draft document on the new pointer-passing interfaces

Justifications presented in the proposal claim hardwired constants for mandatory lock and key style pointer value receiving are a great idea because SQL can't generate constant space strings. And, this is true provided the executable is secret and remote. I know there are a lot of web server

Re: [sqlite] rowid as foreign key

Thank you, Keith. I realize this. I have a (parent) table that does not explicitly define primary key --- a unique identifier of the row. I need to temporarily create a child table that "extends" the row, adds columns to it. I wanted to use foreign keys on internal rowid column to link them.

Re: [sqlite] VALUES clause quirk or bug?

You should NOT be relying on column names UNLESS you set them yourself. -Ursprüngliche Nachricht- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von petern Gesendet: Samstag, 08. Juli 2017 21:37 An: SQLite mailing list

Re: [sqlite] Concurrent reads for VTs with in-memory data structures

We are using a shared memory segment (created during application startup) to contain the data records, but you could also use a memory mapped file. This will keep the static data identical across all connections and processes. When writing your VT module, consider giving it a readonly/readwrite

Re: [sqlite] Doc bug. sqlite3_value_subtype() sqlite3_result_subtype() missing from obtaining/setting pages

There is no sqlite3_result_subtype() becuase there is no sqlite3_bind_subtype() becuase the subtype of a value cannot be stored in the database. That is my point. I don't know what you mean by your second paragraph, but subtype here is just an attribute of a value, similar to it's type (in

Re: [sqlite] New draft document on the new pointer-passing interfaces

> Le 24 juil. 2017 à 13:54, Richard Hipp a écrit : > > https://www.sqlite.org/draft/bindptr.html Thank you very much for this detailed rationale! Gwendal Roué ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] UPDATE database using parameters

On 7/22/17, 1:46 AM, "sqlite-users on behalf of Keith Medcalf" wrote: > Not very well. How do you think "drive by downloads" work? Javascript in > browsers is the most dangerous thing ever invented! I think the

[sqlite] New draft document on the new pointer-passing interfaces

https://www.sqlite.org/draft/bindptr.html -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] New draft document on the new pointer-passing interfaces

>https://www.sqlite.org/draft/bindptr.html Thank you very much for this, detailed, informative write-up, Dr Hipp. It's very helpful to see the sensible rationale behind the new interfaces. Thanks for continuing to enhance the API! ___ sqlite-users