On Thursday, 23 May, 2019 14:39, Jens Alfke wrote:
>> On May 22, 2019, at 8:16 PM, Keith Medcalf
>wrote:
>> Basically, User Defined Types (UDT) were implemented in a fashion
>analgous to a C++ class (remember that at this time C++ was just a
>pre-processor for C and a C++ class was nothing
> On May 22, 2019, at 8:16 PM, Keith Medcalf wrote:
>
> Basically, User Defined Types (UDT) were implemented in a fashion analgous to
> a C++ class (remember that at this time C++ was just a pre-processor for C
> and a C++ class was nothing more than a struct and mangled function names to
>
On Wed, 22 May 2019 21:16:04 -0600
"Keith Medcalf" wrote:
> Basically, when you declared something as a UDT you were giving a
> "blob" a type-domain. Whenever you tried to do something with a UDT
> a "mangled function name" was generated that took that blob as the
> first argument and you
On Wednesday, 22 May, 2019 16:56, James K. Lowden
wrote:
>On Wed, 22 May 2019 14:20:11 -0600
>"Keith Medcalf" wrote:
>> (such as was added to DB2 back in the late 80's early 90's, and
>> which I do not think anyone else has implemented as nicely anywhere
>> else)
>That's an interesting
-users-bounces at mailinglists.sqlite.org] On Behalf Of
Jean-Christophe Deschamps
Sent: Tuesday, 9 June 2015 5:16 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] User-defined types -- in Andl
At 08:27 09/06/2015, you wrote:
>Andl is at a slightly higher level than
sage-
From: sqlite-users-boun...@mailinglists.sqlite.org
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Petite
Abeille
Sent: Monday, 15 June 2015 1:56 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] User-defined types -- in Andl
> On Jun 14, 2015, at
te-users-bounces at mailinglists.sqlite.org] On Behalf Of
Jean-Christophe Deschamps
Sent: Tuesday, 9 June 2015 10:54 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] User-defined types -- in Andl
At 13:50 09/06/2015, you wrote:
>BTW I don't remember the last
> On Jun 14, 2015, at 4:01 PM, david at andl.org wrote:
>
> First, I added a RECURSE() function to Andl, similar to the CTE in SQLite.
Nice.
> The Mandelbrot algorithm looks like this.
Could we see something more, hmmm, pedestrian? Perhaps a simple recursive
query, showing, say, all the
Message-
From: sqlite-users-boun...@mailinglists.sqlite.org
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Richard
Hipp
Sent: Thursday, 11 June 2015 2:01 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] User-defined types -- in Andl
On 6/9/15, david
ounces at mailinglists.sqlite.org] On Behalf Of Richard
Hipp
Sent: Friday, 5 June 2015 7:27 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] User-defined types
On 6/4/15, Darko Volaric < <mailto:lists at darko.org> lists at darko.org>
wrote:
> My point about JSON, etc is th
Language - andl.org
-Original Message-
From: sqlite-users-boun...@mailinglists.sqlite.org
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Dominique
Devienne
Sent: Tuesday, 9 June 2015 9:57 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] User-defined
-bounces at mailinglists.sqlite.org] On Behalf Of
david at andl.org
Sent: Tuesday, 9 June 2015 9:51 PM
To: 'General Discussion of SQLite Database'
Subject: Re: [sqlite] User-defined types -- in Andl
Thank you. Exactly so. One of the problems with this kind of project is
finding 'good enough
> On Jun 9, 2015, at 2:53 PM, Jean-Christophe Deschamps
> wrote:
>
> Most probably! I can imagine that you don't encounter such style in common
> business-like environments.
Just for ?corporate' fun: analytic recursive common table expression - oh, my?
with
Clock( start_at, end_at,
On 6/9/15, david at andl.org wrote:
> I don't remember the last time I saw SQL like this. Understanding it
> might be the challenge...
I'll be giving a talk on CTEs this Saturday at the Southeastern
Linuxfest (http://www.southeastlinuxfest.org/) during which I will
explain and demonstrate how to
] User-defined types -- in Andl
At 08:27 09/06/2015, you wrote:
>Andl is at a slightly higher level than SQL for writing simple queries.
>Where it shines is writing complex queries that involve user-defined
>types, custom transformations and custom aggregations. For complex
&g
Language - andl.org
-Original Message-
From: sqlite-users-boun...@mailinglists.sqlite.org
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Nelson,
Erik - 2
Sent: Monday, 8 June 2015 11:51 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] User-defined types
-users-bounces at mailinglists.sqlite.org] On Behalf Of Eduardo
Morras
Sent: Tuesday, 9 June 2015 4:02 AM
To: sqlite-users at mailinglists.sqlite.org
Subject: Re: [sqlite] User-defined types -- in Andl
On Mon, 8 Jun 2015 15:28:11 +1000
wrote:
> Thanks for pointing it out, but I knew that the best
At 13:50 09/06/2015, you wrote:
>BTW I don't remember the last time I saw SQL like this. Understanding it
>might be the challenge
`---
Most probably! I can imagine that you don't encounter such style in
common business-like environments.
Take your time, this SQL piece is clearly beyond
On Tue, Jun 9, 2015 at 1:50 PM, wrote:
> Thank you. Exactly so. One of the problems with this kind of project is
> finding 'good enough' challenges to tackle.
>
See also from the CTE doc:
- https://www.sqlite.org/lang_with.html#sudoku
- https://www.sqlite.org/lang_with.html#mandelbrot
Thanks,
At 08:27 09/06/2015, you wrote:
>Andl is at a slightly higher level than SQL for writing simple queries.
>Where it shines is writing complex queries that involve user-defined
>types,
>custom transformations and custom aggregations. For complex relational
>operations there is nothing I know
I hope you do try it. I'm looking for feedback.
Sorry about the C#. Problem is, I'm way more productive in C# than any other
language. C/C++ is just too slow to get things done and Java is still lagging.
It would have taken far longer to do the SQLite C interface without .NET
interop (JNI is
On Mon, 8 Jun 2015 15:28:11 +1000
wrote:
> Thanks for pointing it out, but I knew that the best way to show off a
> language is with examples. That's why there are nine sample Andl
> scripts comprising dozens of individual examples in the Samples
> folder. My guess is if that you're asking me to
Message-
From: sqlite-users-boun...@mailinglists.sqlite.org
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Simon
Slavin
Sent: Monday, 8 June 2015 12:26 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] User-defined types -- in Andl
On 8 Jun 2015, at 3:14am
ounces at mailinglists.sqlite.org] On Behalf Of Richard
Hipp
Sent: Friday, 5 June 2015 7:27 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] User-defined types
On 6/4/15, Darko Volaric < <mailto:lists at darko.org> lists at darko.org>
wrote:
> My point about JSON, etc is th
ounces at mailinglists.sqlite.org] On Behalf Of Richard
Hipp
Sent: Friday, 5 June 2015 7:27 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] User-defined types
On 6/4/15, Darko Volaric < <mailto:lists at darko.org> lists at darko.org>
wrote:
> My point about JSON, etc is th
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Simon
Slavin
Sent: Monday, 8 June 2015 12:23 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] User-defined types -- in Andl
On 8 Jun 2015, at 3:12am, wrote:
> Is there a PDF? No, but that's a good idea. Did you ch
david at andl.org wrote on Monday, June 08, 2015 9:23 AM
>
> Ultimately, I don't think it will really matter, because the role of
> Andl is to be platform independent. Do you care what your SQL product
> is written in?
>
Absolutely. I wouldn't be using SQLite if it wasn't C/C++, and I suspect
On 8 Jun 2015, at 6:28am, wrote:
> Thanks for pointing it out, but I knew that the best way to show off a
> language is with examples. That's why there are nine sample Andl scripts
> comprising dozens of individual examples in the Samples folder. My guess is
> if that you're asking me to write
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Simon
Slavin
Sent: Monday, 8 June 2015 4:00 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] User-defined types -- in Andl
On 7 Jun 2015, at 6:51pm, Scott Doctor wrote:
> Do you have a PDF that explains the langu
...@mailinglists.sqlite.org
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Scott
Doctor
Sent: Monday, 8 June 2015 3:52 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] User-defined types -- in Andl
Do you have a PDF that explains the language?
My opinion
On Sun, Jun 7, 2015 at 4:17 AM, wrote:
> I've been reading this thread with great interest. It parallels the project
> I've been working on: Andl.
>
> Andl is A New Database Language.
>
> Andl does what SQL does, but it is not SQL. Andl has been developed as a
> fully featured database
Any properly written documentation on any subject always begins with an
executive summary (no more than a few pages), an overview (usually a
dozen more pages), then gets into the nitty gritty.
Consider if I want you to write a paragraph in Egyptian Hieroglyphics.
So I provide you with a few
On 8 Jun 2015, at 3:14am, wrote:
> I suggest you just read the samples off GitHub. They cover the entire
> language. Download the binary, run them and you see what they do.
Sorry but no. You have it reversed. Your code isn't going to touch my
computer unless you have already convinced me
On 8 Jun 2015, at 3:12am, wrote:
> Is there a PDF? No, but that's a good idea. Did you check out the samples?
> They cover the entire language, and I could turn those into a PDF much
> faster than a real language. It would take about a month to write a decent
> tutorial and reference, but that
On 2015-06-04 03:04, Darko Volaric wrote:
> Regarding PgSQL, an advantage of encoding your own binary types is that you
> can copy them straight into your code and execute with them directly - I
> use the same encoding/data structures throughout and they serve my code and
> requirements instead of
Volaric
Sent: Thursday, 4 June 2015 8:55 AM
To: General Discussion of SQLite Database; ott at mirix.org
Subject: Re: [sqlite] User-defined types
I've tackled this problem from a couple of different angles. My goal was to
allow arbitrary user defined types, based on the builtin types (essentially
Language - andl.org
-Original Message-
From: sqlite-users-boun...@mailinglists.sqlite.org
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Richard
Hipp
Sent: Friday, 5 June 2015 9:11 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] User-defined types
On 6
On 7 Jun 2015, at 6:51pm, Scott Doctor wrote:
> Do you have a PDF that explains the language?
There are plenty of blog entries which explain the language. I spent more time
looking for some examples (I understand better from examples) and eventually
found one.
Simon.
So we are supposed to learn this new language by osmosis?
Scott Doctor
scott at scottdoctor.com
On 6/7/2015 11:00 AM, Simon Slavin wrote:
> On 7 Jun 2015, at 6:51pm, Scott Doctor wrote:
>
>> Do you have a PDF that explains the language?
> There are plenty of blog entries which
Regards
> David M Bennett FACS
>
> Andl - A New Database Language - andl.org
>
> -Original Message-
> From: sqlite-users-bounces at mailinglists.sqlite.org
> [mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Darko
> Volaric
> Sent: Thursday, 4 June
On Thu, 4 Jun 2015 15:11:55 -0700
Darko Volaric wrote:
> Are you seriously saying that that SQL syntax is friendly? How can you
> defend SQL syntax other than on grounds of history or
> standardization?
The first and best defense of SQL is that it has at least some
basis in the relational
On Fri, 5 Jun 2015 13:07:59 -0400
Stephen Chrzanowski wrote:
> If N-Tier software development is 'annoying' and you are not happy,
> either get help by other members of your team, or, find a different
> hobby, because anything less than 3-tier programming dealing with
> multiple languages,
On 5 Jun 2015, at 3:05pm, Don V Nielsen wrote:
> I do all kinds of --stuff--
> using Ruby and PHP. And the --stuff-- gets translated to SQL and sent to
> my favorite db, Sqlite.
I find it very annoying that in order to do good Web-facing systems I have to
know all the following:
HTML (and
Yes, the relational model is the key, that is my point. The SQL language is
an entirely arbitrary syntax applied to it. You don't need it to work a
relational database, just like you don't have to program in C to write a
program for a typical processor.
I don't care about how many applications
On Fri, Jun 5, 2015 at 11:07 AM, Stephen Chrzanowski
wrote:
> First, who said that you had to keep all 6 sets of languages in your head
> at once? I've never been told that, and I've been doing software
> development since I was 8, taken several training courses in elementary,
> high school,
First, who said that you had to keep all 6 sets of languages in your head
at once? I've never been told that, and I've been doing software
development since I was 8, taken several training courses in elementary,
high school, college, and while employed by three different companies (At
different
> How can you defend SQL syntax other than on grounds of history or
standardization?
Short answer: QWERTY.
Long answer: IBM mainframe DOS -> Z/OS. A 1960's o/s that is still
supported by the inner workings of its most modern o/s.
There's is nothing wrong with supporting the past. Sometimes
What you're looking for seems similar to LINQ to SQLite (System.Data.SQLite).
When programming in C#, I don't code any SQL. I use a strongly-typed interface
that then generates SQL queries in the background.
Besides LINQ, you could create another interface that suits your needs, and
that can
There's a bit of confusion as to what I'm actually proposing. I can't reply
to everyone so I'll just post the APIs and/or patches when they're done and
we can argue those on their merits.
On Thu, Jun 4, 2015 at 5:03 PM, Darko Volaric wrote:
> Well, I've been using SQL for about 30 years so I'm
On 2015-06-05 12:11 AM, Darko Volaric wrote:
> Are you seriously saying that that SQL syntax is friendly? How can you
> defend SQL syntax other than on grounds of history or standardization? If
> you're more comfortable and familiar with JSON the yes it is easier and you
> can avoid an
On 5 Jun 2015, at 12:11am, Richard Hipp wrote:
> I just want to ensure that if, after working on your new approach for
> a while, you eventually decide that SQL isn't quite as bad a language
> as you originally thought it was, that you don't come back and say I
> didn't warn you.
I'm on my
On 2015-06-04 11:16 PM, Darko Volaric wrote:
> My point about JSON, etc is that there is no reason not to use that as a
> query language if that makes it easier. If your system is efficient with
> JSON, why not accept a query that is formatted as JSON? It's not
> semantically different to SQL
On 4 Jun 2015, at 11:11pm, Darko Volaric wrote:
> Are you seriously saying that that SQL syntax is friendly? How can you
> defend SQL syntax other than on grounds of history or standardization? If
> you're more comfortable and familiar with JSON the yes it is easier and you
> can avoid an
On 4 Jun 2015, at 10:16pm, Darko Volaric wrote:
> Here's an example (with a roughly
> JSON notation):
>
> {
> operation: "insert"
> table: "blah"
> columns: ["a", "b", "c"]
> values: [1.3, 2.0, 3.1]
> on-conflict: "replace"
> }
>
> That is equivalent to an INSERT SQL statement, but why
On 6/4/15, Darko Volaric wrote:
>
> What is motivating this for me is that I generate many unique queries in my
> code for almost any operation. Converting those to SQL is error prone and
> uses a lot of memory compared to the operation involved. The database
> engine is so fast and efficient yet
On 2015-06-05 12:11 AM, Darko Volaric wrote:
>I now regret using JSON as an example since everyone wants me to
>convert SQL to JSON for them now, but my point isn't any particular
>notation, I want an API of sorts instead of a notation or syntax. Then
>you can adapt anything you like and make
If you really want your own types, you could always bundle with ASN.1 and
store the result as a blob.
On Thu, Jun 4, 2015 at 4:52 PM, Dominique Devienne
wrote:
> On Thu, Jun 4, 2015 at 3:04 AM, Darko Volaric wrote:
>
> > In my case I'm already modifying and maintaining my own version of
>
On Thu, Jun 04, 2015 at 03:36:34PM -0700, Darko Volaric wrote:
> I now regret using JSON as an example since everyone wants me to convert
> [...]
So you don't like the SQL language, but if you're after UDTs and your
first stop is to design a different language (or merely make it easier
for you to
On Thu, Jun 4, 2015 at 4:21 PM, Darko Volaric wrote:
> I'm saying that SQL is alien to the platform it's being used on and native
> is better. I'm trying to make a general point (in vain it seems), I don't
> use JSON.
>
{bunch of stuff snipped}
I understand where you're coming from, I think. I
On 6/4/15, Darko Volaric wrote:
> My point about JSON, etc is that there is no reason not to use that as a
> query language if that makes it easier. If your system is efficient with
> JSON, why not accept a query that is formatted as JSON? It's not
> semantically different to SQL syntax. Here's
Well, I've been using SQL for about 30 years so I'm unlikely to change my
view, but I think you bring up a much more important point: instead of
arguing online I should get back to work!
On Thu, Jun 4, 2015 at 4:11 PM, Richard Hipp wrote:
> On 6/4/15, Darko Volaric wrote:
> >
> > What is
Just write your program in C. Use the C syntax to do whatever
you want and you have full control over the minutiae.
Scott Doctor
scott at scottdoctor.com
--
> On 6/4/15, Darko Volaric wrote:
>> What is motivating this for me is that I generate many unique
On Thu, Jun 04, 2015 at 02:16:22PM -0700, Darko Volaric wrote:
> {
> operation: "insert"
> table: "blah"
> columns: ["a", "b", "c"]
> values: [1.3, 2.0, 3.1]
> on-conflict: "replace"
> }
I do this all the time. It's trivial enough to generate SQL from that
sort of thing. If you have
I now regret using JSON as an example since everyone wants me to convert
SQL to JSON for them now, but my point isn't any particular notation, I
want an API of sorts instead of a notation or syntax. Then you can adapt
anything you like and make it efficient with the platform you're using. So
for
I'm saying that SQL is alien to the platform it's being used on and native
is better. I'm trying to make a general point (in vain it seems), I don't
use JSON.
On Thu, Jun 4, 2015 at 2:46 PM, Simon Slavin wrote:
>
> On 4 Jun 2015, at 10:16pm, Darko Volaric wrote:
>
> > Here's an example (with a
Yes, you can do that but I'm trying to remove steps and conversions, not
add more. My point is that a more native interface is better than SQL.
Yes it's basic, but as I said, a first step. I'm making changes to one
part, making changes to another part makes no difference. The fork has been
Are you seriously saying that that SQL syntax is friendly? How can you
defend SQL syntax other than on grounds of history or standardization? If
you're more comfortable and familiar with JSON the yes it is easier and you
can avoid an unnecessary conversion step.
If you're using JavaScript you'd
My point about JSON, etc is that there is no reason not to use that as a
query language if that makes it easier. If your system is efficient with
JSON, why not accept a query that is formatted as JSON? It's not
semantically different to SQL syntax. Here's an example (with a roughly
JSON notation):
On Thu, Jun 04, 2015 at 11:45:28AM -0700, Darko Volaric wrote:
> Which sort of leads me to my next feature, which is bypassing the SQL
> language. [...]
I like SQL, but sure, if the compiler worked by first parsing into an
AST, and if the AST were enough of an interface (versioned, though not
On Thu, Jun 04, 2015 at 10:54:16AM +0200, Dominique Devienne wrote:
> On Thu, Jun 4, 2015 at 10:20 AM, Christopher Vance
> wrote:
> > If you really want your own types, you could always bundle with ASN.1 and
> > store the result as a blob.
FYI, Heimdal has a very nice, small, simple, featureful,
On Wed, Jun 03, 2015 at 06:04:29PM -0700, Darko Volaric wrote:
> Yep, references a another one. Just like the functions, you have to join on
> the user type information, add it to constraints, etc.
Once you're extending SQLite3 proper the referential integrity problem
goes away (being no
On Thu, Jun 4, 2015 at 1:54 AM, Dominique Devienne
wrote:
> On Thu, Jun 4, 2015 at 10:20 AM, Christopher Vance
> wrote:
>> If you really want your own types, you could always bundle with ASN.1 and
>> store the result as a blob.
>
> Or Protobuf, or ... But you're back to option 1, you must
Which sort of leads me to my next feature, which is bypassing the SQL
language. Why use that crusty old syntax when it's equally expressible in
JSON, XML or something else. Again I see it just as an API, callable by
whatever parser you want, or none at all, if your code generates queries
directly.
On Thu, Jun 4, 2015 at 10:20 AM, Christopher Vance
wrote:
> If you really want your own types, you could always bundle with ASN.1 and
> store the result as a blob.
>
Or Protobuf, or ... But you're back to option 1, you must store somewhere
that knowledge, and it's an app-convention, SQL and
On Thu, Jun 4, 2015 at 3:04 AM, Darko Volaric wrote:
> In my case I'm already modifying and maintaining my own version of SQLite.
> [...]. The last time I brought these ideas up I was
> practically chased off by a mob waving pitchforks and torches. Apparently
> almost no-one thinks user defined
That's an entirely valid point, but didn't come up in the discussions if
memory serves. It was the "you don't know what you're doing and don't
understand databases" which I thought was an odd response, but that's all
irrelevant.
I agree that feature bloat is not a good idea (hello, PgSQL!) and I
On Wed, Jun 03, 2015 at 03:55:04PM -0700, Darko Volaric wrote:
> I've tackled this problem from a couple of different angles. My goal was to
> allow arbitrary user defined types, based on the builtin types (essentially
> subtypes of the existing types), with a minimum of work and minimum
>
Yep, references a another one. Just like the functions, you have to join on
the user type information, add it to constraints, etc.
In my case I'm already modifying and maintaining my own version of SQLite.
My project is basically a database with a lot of extensions. Submitting
patches is not an
I've tackled this problem from a couple of different angles. My goal was to
allow arbitrary user defined types, based on the builtin types (essentially
subtypes of the existing types), with a minimum of work and minimum
disruption of the normal/existing use of the database and API.
The approaches
I want to define user-defined types, i.e. types not SQLite has not
built-in and make sure that I didn't overlook something. Is it correct
that values of user-defined types should be stored as text and have a
collation defined if there is an order relation for the type if the type
cannot be
On 5/27/15, Matthias-Christian Ott wrote:
>
> Is there another way to define user-defined types despite this method
> and virtual tables?
>
I know of no other.
--
D. Richard Hipp
drh at sqlite.org
81 matches
Mail list logo
