> On Oct 26, 2019, at 5:12 PM, Thomas Kurz wrote:
>
> Geospatial support would be one of the features I would *LOVE* to see in
> SQLite :-)
SQLite has had geospatial support for years via the r-tree extension, and more
recently GeoJSON.
As for time stamps ... I’ve been using SQLite since
On October 26, 2019 8:07:57 p.m. EDT, Thomas Kurz
wrote:
>To me, the most puzzling thing is the lack of full ALTER TABLE support
>(DROP COLUMN, MODIFY COLUMN, ADD CONSTRAINT, DROP CONSTRAINT).
>Modifying tables is some kind of science in SQLite, and thus, very
>error-prone.
I'd second this
> I suspect you are used to database servers, and haven’t used SQLite as an
> embedded library inside an app
Yes and no ;-)
I have used database servers, and I am currently (for about 2 years) using (and
appreciating!) SQLite library.
> Full text search is very common
Yes, of course. I
> Feel free to make suggestions. Which missing feature or features causes
you the most bother?
Thanks, Dan.
To me, the most puzzling thing is the lack of full ALTER TABLE support (DROP
COLUMN, MODIFY COLUMN, ADD CONSTRAINT, DROP CONSTRAINT). Modifying tables is
some kind of science in SQLite,
> The features you name don't take away from the "liteness", they are all quite
small and useful.
Yes of course they are useful, I wouldn't deny that. But they are prioritized
over SQL-basics, that's what I'm confused about.
___
sqlite-users mailing
While on errata for the shell, there is a little cosmetic bugaboo with the
output of .eqp full:
(1) When .mode col is in effect the "explain" column widths are used, not the
.width or the defaults used when .eqp full is not in effect.
(2) .head on is ignored -- table output column headers are
Thanks for the report. This problem is fixed on trunk.
To be clear, this is an issue in the "sqlite3" shell command, not in
the SQLite core.
Also, it is an issue in the deprecated and undocumented ".explain on"
command of the shell. Years ago, it used to be necessary to run
".explain on" prior
Dne 25. 10. 19 v 21:41 Keith Medcalf napsal(a):
> The sqlite3 command line shell already does this. see function process_input
Thanks, it helped.
I see that it checks whether the input contains a semicolon and only
then it calls sqlite3_complete(). So I implemented it in a similar way
in C++.
I am running sqlite3 on a Linux Mint 18 desktop.
I first realized the problem with the stock sqlite3 client 3.11.0
2016-02-15 17:29:24 3d862f207e3adc00f78066799ac5a8c282430a5f.
I confirmed it still exists with the currently published most recent
version 3.30.1 2019-10-10 20:19:45
Unsuscribe
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
On 26 Oct 2019, at 4:44am, Keith Medcalf wrote:
> If the identifier is also a keyword and used in a location where it could be
> that keyword
Actually, any location. A SQL parser may pick out a SQL keyword even if it's
in the wrong place in the wrong kind of SQL statement. And then issue a
11 matches
Mail list logo