> On Oct 27, 2019, at 1:50 PM, Thomas Kurz wrote:
>
> But not compatible to standards from Open Geospatial Consortium, as far as I
> know.
That's the nice thing about standards: there are so many of them.
> Which requires additional conversions, and considering that geodata usually
> have
Number one on my wishlist.
UNSIGNED
Wanted for ordering more than anything else
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> SQLite has had geospatial support for years via the r-tree extension, and
> more recently GeoJSON.
But not compatible to standards from Open Geospatial Consortium, as far as I
know. Which requires additional conversions, and considering that geodata
usually have sizes of a GB or more, this is
On Sunday, 27 October, 2019 13:30, Richard Damon
wrote:
>On 10/27/19 10:24 AM, Simon Slavin wrote:
>> On 27 Oct 2019, at 9:12am, Thomas Kurz wrote:
>>> the discussion standard deviation has shown that at least STDEV and
>>> POWER would be very helpful if they part of SQLite core.
>> These a
On 27 Oct 2019, at 7:43pm, Richard Damon wrote:
> My one thought about fuller ALTER TABLE support would be that since
> SQLite stores the schema as the simple CREATE TABLE command, that ALTER
> TABLE needs to know how to edit that string to match the changes, where
> simple adds are much easier t
On 10/26/19 8:07 PM, Thomas Kurz wrote:
>> 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). Mo
On 10/27/19 10:24 AM, Simon Slavin wrote:
> On 27 Oct 2019, at 9:12am, Thomas Kurz wrote:
>
>> the discussion standard deviation has shown that at least STDEV and POWER
>> would be very helpful if they part of SQLite core.
> These are presentation issues. Not database issues. The results of su
Dne 27. 10. 19 v 15:24 Simon Slavin napsal(a):
> And I agree with you on RIGHT JOIN: it may duplicate what can be done with
> LEFT JOIN but many SQL facilities are duplicates. It's in SQL92 and people
> expect to see it.
+1 This would increase portability of SQL scripts – it would be easier
to
Dne 27. 10. 19 v 10:12 Thomas Kurz napsal(a):
> at least some basic math would be very helpful as well. I don't want to
> suggest a complete math support, that would really be far away from liteness
Generally speaking, it might be difficult to say where is the line
between „light“ and „heavy“. Bu
Hi Simon,
Especially since it can't do something more fundamental than STDEV:
return all surnames starting with the Unicode character 'Ã
'.
Reconsider as this works fine.
JcD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http
On 27 Oct 2019, at 9:12am, Thomas Kurz wrote:
> the discussion standard deviation has shown that at least STDEV and POWER
> would be very helpful if they part of SQLite core.
These are presentation issues. Not database issues. The results of such
calculations are unlikely to be used to deci
> What do you mean by "SQL-basics"?
I forgot to mention that at least some basic math would be very helpful as
well. I don't want to suggest a complete math support, that would really be far
away from liteness, but the discussion standard deviation has shown that at
least STDEV and POWER would
> Omitting RIGHT JOIN is good, that's a misfeature and LEFT JOIN does
> everything
useful it does.
With all dear respect, but I don't think that it is up to you to define what a
"feature" and a "misfeature" is. iirc, RIGHT JOIN is declared in SQL92, it is
part of the SQL standard, and therefor
On 2019-10-26 4:38 p.m., Thomas Kurz wrote:
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.
What do you mean by "SQL-
On Oct 26, 2019, at 6:28 PM, J. King wrote:
>
> a good designer will choose a good schema from the start and thus rarely need
> to change it
When you add new features to a long-lived application, you may occasionally
have to ALTER the table(s) the app uses to allow the new feature. My company
> 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 200
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 (th
> 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 didn't
> 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
On 10/20/19 11:03 PM, Rowan Worth wrote:
> On Sun, 20 Oct 2019 at 17:04, Simon Slavin wrote:
>
>> Another common request is full support for Unicode (searching, sorting,
>> length()). But even just the tables required to identify character
>> boundaries are huge.
>>
> Nitpick: there are no tables
On Oct 20, 2019, at 9:20 PM, Darren Duncan wrote:
>
> Rowan, you're talking about Unicode codepoints; however, Unicode graphemes,
> what typical humans consider to be characters, are sequences of 1..N
> codepoints, example a letter plus an accent that get composed together, and
> this is what
Rowan, you're talking about Unicode codepoints; however, Unicode graphemes, what
typical humans consider to be characters, are sequences of 1..N codepoints,
example a letter plus an accent that get composed together, and this is what
takes those large tables; this is related to Unicode Normal Fo
On Sun, 20 Oct 2019 at 17:04, Simon Slavin wrote:
> Another common request is full support for Unicode (searching, sorting,
> length()). But even just the tables required to identify character
> boundaries are huge.
>
Nitpick: there are no tables required to identify character boundaries. For
u
> On Oct 20, 2019, at 12:53 AM, Thomas Kurz wrote:
>
> many "playground" gadgets keep being implemented (like virtual columns,
> virtual tables, FTS3/4/5, ...),
I suspect you are used to database servers, and haven’t used SQLite as an
embedded library inside an app (its primary use case.) Vi
On 20/10/62 14:53, Thomas Kurz wrote:
I'd kindly ask whether there is some sort of roadmap for SQLite development?
Someone recently pointed out how much he loves the "lite" and well-thought features. I cannot see
that: I observe that many "playground" gadgets keep being implemented (like virtu
On 20 Oct 2019, at 8:53am, Thomas Kurz wrote:
> I'd kindly ask whether there is some sort of roadmap for SQLite development?
Only private to the developers, probably just mentioning whatever they're
worried about at the moment. Nothing public.
> Someone recently pointed out how much he loves
On 2019-10-20 12:53 a.m., Thomas Kurz wrote:
I'd kindly ask whether there is some sort of roadmap for SQLite development?
Someone recently pointed out how much he loves the "lite" and well-thought features. I cannot see
that: I observe that many "playground" gadgets keep being implemented (like
I'd kindly ask whether there is some sort of roadmap for SQLite development?
Someone recently pointed out how much he loves the "lite" and well-thought
features. I cannot see that: I observe that many "playground" gadgets keep
being implemented (like virtual columns, virtual tables, FTS3/4/5, ..
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shaun Seckman (Firaxis) wrote:
> The SQLite Consortium membership would be great but so far this
> newsgroup has answered every single one of my questions within a 2 hour
> window of posting..for free!
The consortium membership is not about answerin
On Mon, Nov 2, 2009 at 5:26 PM, Scott Hess wrote:
> And always remember that it's cheap to ask
> - maybe the feature is in there, you just mis-understood something
Whereby "it's cheap to ask" implies that it is "inexpensive to ask"
and not "to ask is cowardly, impolite or deserving of contempt."
On Mon, Nov 2, 2009 at 3:56 PM, Shaun Seckman (Firaxis)
wrote:
> The SQLite Consortium membership would be great but so far this
> newsgroup has answered every single one of my questions within a 2 hour
> window of posting..for free! (you guys frickin rock.) So SQLite
> development is purely gui
, November 02, 2009 4:14 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Roadmap for SQLite
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shaun Seckman (Firaxis) wrote:
> I'm really interested in finding out what sort of major features or
> tweaks are planned to b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shaun Seckman (Firaxis) wrote:
> I'm really interested in finding out what sort of major features or
> tweaks are planned to be in upcoming releases (within the next 6
> months).
You get what you ask for :-) Have a look at these two pages:
http://
Hello,
Is there any sort of development road map for SQLite?
I'm really interested in finding out what sort of major features or
tweaks are planned to be in upcoming releases (within the next 6
months). The foreign key constraint feature came as a pleasant surprise
but ended up in
Is there a roadmap of major planned features in upcoming releases? I didn't
see anything on the wiki or site..
Thanks,
Sam
---
We're Hiring! Seeking a passionate developer to join our team building
products. Position is in the Washington D.C. metro are
36 matches
Mail list logo