Re: [sqlite] SQLite 3.20.0 postponed

[Gwendal Roué]

> Le 22 juil. 2017 à 08:14, Gwendal Roué  a écrit :
> 
> Still, I feel that static strings are a weird way to define keys. For 
> example, value subtypes in SQLite have the same requirement of needing 
> "unique subtype identifiers", and those subtypes are, today, ints. Not 
> strings compared with strcmp(). Is there anything special with pointer 
> functions that have them require something different than ints for 
> identifying pointers?

Answering my own question: with int keys, it would be very easy to implement 
"interfaces that provide access to pointers of any type the user wants", that 
Richard does not want to support. Static strings indeed are a way to lock the 
API to "narrowly defined purposes".

OK, I'm good :-) Thanks a lot for your explanations, Richard!

Gwendal Roué

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.20.0 postponed

[Gwendal Roué]

> Le 21 juil. 2017 à 18:50, Richard Hipp  a écrit :
> 
> On 7/21/17, Gwendal Roué  wrote:
>> 
>> First, this strcmp() give a lot of work to languages that wrap SQLite and
>> lack support for "static strings".
> 
> But sqlite3_result_pointer() and sqlite3_bind_pointer() are not
> invoked from those languages.  The _pointer() routines are invoked
> from C, and C does easily support string literals that are static
> strings.
> 
> A C-language wrapper around sqlite3_result_pointer() and
> sqlite3_bind_pointer() that interfaces to the non-static-string
> language can simply insert the required static string.
> 
> We do not want the static string to be a parameter to a generic
> higher-level interface.  That defeats the purpose of the static
> string.  Remember, the string is a "pointer type".  We do not want to
> support interfaces that provide access to pointers of any type the
> user wants.  We are not trying to recreate C++ templates or other
> interfaces that work with arbitrary types.  Each use of _pointer() is
> intended to be used for a single narrowly defined purpose.

If I understand you correctly, no wrapper library in a foreign language should 
ever claim "New! Support for pointer functions introduced in SQLite 3.20.0".

Instead, it could claim: "New! Support for SQLite 3.32.0, including the new 
FTS6 full-text engine". The support for this hypothetical FTS6 engine would 
imply the use of pointer functions by the wrapper, but not by its clients. FTS6 
would have its own "narrowly defined purposes" for function pointers.

I see the point, and the fact that you don't want "to support interfaces that 
provide access to pointers of any type the user wants". I don't want to discuss 
that.

Still, I feel that static strings are a weird way to define keys. For example, 
value subtypes in SQLite have the same requirement of needing "unique subtype 
identifiers", and those subtypes are, today, ints. Not strings compared with 
strcmp(). Is there anything special with pointer functions that have them 
require something different than ints for identifying pointers?

Gwendal Roué

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.20.0 postponed

[petern]

Nobody is storing pointers.  Where do you get that idea?

If struct pointer is passed through sqlite3_result_blob() with destructor
callback disposition instead of SQLITE_TRANSIENT, the value received is a
BLOB result pointed to the (void*) memory location of that exact supplied
struct's memory.   That's how it works now and independently of the 3.20.00
proposal.

Now, if that BLOB is persisted you get a copy of those bits onto the disk.
So what?  Maybe that makes sense or maybe not, but the pointer isn't
stored.  The pointer is only available at runtime which is what we're
talking about here.  The question is not about storage.  The question is
how to make the API useful for embedded applications with awareness of the
host's transient objects.   We also learned just now by forum email from
Richard that adding and carrying a native INT type field throughout the
chain of the existing BLOB API is too expensive.  So he went with the
lightweight pseudo-nulls idea.

Take a look at my sample SQL a few emails back if you want to see an
application.  Most of the time the operational result of passing pointers
to native objects through the DB API with respect to storage is null.  The
desired operation is often a side effect like sending something over the
network or efficiently keeping track of whatever summarized results in a
memory vtable.  The important part from my perspective is that the DB can
store precise details about embedded object initializations and
interactions without having to invent a storage format for every little
setting or add serialization methods to third party library objects lacking
serialization operations.











On Fri, Jul 21, 2017 at 3:14 PM, Keith Medcalf <kmedc...@dessus.com> wrote:

>
> Pointers cannot be stored in the database.  They are simply value objects
> that get passed around between bits and pieces -- such as passing a pointer
> from an SQL statement into an extension function or virtual table all
> within the same linkage unit (that is locally within a single process).
> The whole point, I believe, was to prevent pointers from being persisted to
> the database.  And if you foolishly try to store them in the database, then
> the value stored is NULL.  Storing pointers in BLOBs would defeat this
> purpose since you would not be preventing natural selection.
>
> And if I have the purpose wrong, then I really don't understand why there
> needs to be a separate value type for pointers at all ...
>
>
> >-Original Message-
> >From: sqlite-users [mailto:sqlite-users-
> >boun...@mailinglists.sqlite.org] On Behalf Of petern
> >Sent: Friday, 21 July, 2017 14:49
> >To: SQLite mailing list
> >Subject: Re: [sqlite] SQLite 3.20.0 postponed
> >
> >Indeed.  Or Type(T) of long, or sqlite_int64, or whatever is most
> >universal
> >where porting other architectures is concerned. It would be a shame
> >if the
> >API had to be changed later because the integer type chosen couldn't
> >hold a
> >pointer.
> >
> >From there, in a closed compiled host C/C++ setting with the
> >discipline of
> >header files, one may simply perform the stricmp("CARRAY",(const
> >char*) T)
> >cast to T string pointer comparison as desired and leave the API out
> >of
> >that part.  This leaves open the more conventional test of T with
> >enum or
> >#define compile time constant.
> >
> >Now it remains, on the surface, that this new pseudo null pointer API
> >appears redundant in light of the existing BLOB interface and the
> >possibility of simply adding Type(T) versions of those BLOB function
> >signatures to the API.
> >
> >How was adding to the BLOB API ruled out?  Is there a fundamental
> >problem
> >with slightly broadening the BLOB API to deal with typed host
> >objects?
> >Surely returning zero for the Type(T) would be backward compatible,
> >would
> >it not?  Just asking.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >On Fri, Jul 21, 2017 at 12:48 PM, Keith Medcalf <kmedc...@dessus.com>
> >wrote:
> >
> >> On Friday, 21 July, 2017 10:51, Richard Hipp <d...@sqlite.org>
> >wrote:
> >>
> >> > But sqlite3_result_pointer() and sqlite3_bind_pointer() are not
> >> > invoked from those languages.  The _pointer() routines are
> >invoked
> >> > from C, and C does easily support string literals that are static
> >> > strings.
> >>
> >> > A C-language wrapper around sqlite3_result_pointer() and
> >> > sqlite3_bind_pointer() that interfaces to the non-static-string
> >> > language can simply insert the required static string.
> >>
>

Re: [sqlite] SQLite 3.20.0 postponed

[Keith Medcalf]

Pointers cannot be stored in the database.  They are simply value objects that 
get passed around between bits and pieces -- such as passing a pointer from an 
SQL statement into an extension function or virtual table all within the same 
linkage unit (that is locally within a single process).  The whole point, I 
believe, was to prevent pointers from being persisted to the database.  And if 
you foolishly try to store them in the database, then the value stored is NULL. 
 Storing pointers in BLOBs would defeat this purpose since you would not be 
preventing natural selection.

And if I have the purpose wrong, then I really don't understand why there needs 
to be a separate value type for pointers at all ...


>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of petern
>Sent: Friday, 21 July, 2017 14:49
>To: SQLite mailing list
>Subject: Re: [sqlite] SQLite 3.20.0 postponed
>
>Indeed.  Or Type(T) of long, or sqlite_int64, or whatever is most
>universal
>where porting other architectures is concerned. It would be a shame
>if the
>API had to be changed later because the integer type chosen couldn't
>hold a
>pointer.
>
>From there, in a closed compiled host C/C++ setting with the
>discipline of
>header files, one may simply perform the stricmp("CARRAY",(const
>char*) T)
>cast to T string pointer comparison as desired and leave the API out
>of
>that part.  This leaves open the more conventional test of T with
>enum or
>#define compile time constant.
>
>Now it remains, on the surface, that this new pseudo null pointer API
>appears redundant in light of the existing BLOB interface and the
>possibility of simply adding Type(T) versions of those BLOB function
>signatures to the API.
>
>How was adding to the BLOB API ruled out?  Is there a fundamental
>problem
>with slightly broadening the BLOB API to deal with typed host
>objects?
>Surely returning zero for the Type(T) would be backward compatible,
>would
>it not?  Just asking.
>
>
>
>
>
>
>
>
>
>On Fri, Jul 21, 2017 at 12:48 PM, Keith Medcalf <kmedc...@dessus.com>
>wrote:
>
>> On Friday, 21 July, 2017 10:51, Richard Hipp <d...@sqlite.org>
>wrote:
>>
>> > But sqlite3_result_pointer() and sqlite3_bind_pointer() are not
>> > invoked from those languages.  The _pointer() routines are
>invoked
>> > from C, and C does easily support string literals that are static
>> > strings.
>>
>> > A C-language wrapper around sqlite3_result_pointer() and
>> > sqlite3_bind_pointer() that interfaces to the non-static-string
>> > language can simply insert the required static string.
>>
>> Well, yes.  Technically.  Almost everything everywhere is called
>from code
>> written in C.  Very little meaningful anything is written in any
>other
>> language.  So although you may be writing something in Java
>(heavens
>> forbid), Java was written in C.  So in the end, all calls are made
>from
>> software written in C.  This is the way of the world.  Some people
>just
>> like to add lots of syntactical sugar and overhead which eventually
>ends up
>> being C code -- either translated by a preprocessor (as in the case
>of
>> C++), or by a compiler written in C (or written in some other
>language that
>> was written in C ... repeat for as deep down the rabbit hole as you
>need to
>> go).  There are a few self-hosted language compilers that are
>exceptions,
>> but not very many.  And they all started as C before they were re-
>written
>> in themself so they could become self-hosted.
>>
>> However, the change does create a problem when one is using a
>sugary
>> language (for example Python).  It does not know how to bind
>pointers, nor
>> is there any way to pass in a variable static "string" as an extra
>> parameter.  So for example, the carray extension *used* to be able
>to be
>> passed a pointer which was bound as an int (you obtain the pointer
>by
>> allocating a ctypes array and asking for the pointer) -- of course
>this is
>> unsafe if you do something stupid -- but then almost everything
>including
>> making a nice cuppa tea is unsafe if you do something stupid.
>>
>> I have fiddled with defining a new type for the python interface
>that can
>> contain a string and a reference to a ctypes object (so that the
>string
>> stays in scope and the ctypes array stays in scope as long as the
>outer
>> object stays in scope), and then adding an addition bind detection
>for this
>> type of object.  It works but it is far more complicated t

Re: [sqlite] SQLite 3.20.0 postponed

[Richard Hipp]

On 7/21/17, petern  wrote:
>
> How was adding to the BLOB API ruled out?

It uses extra memory and CPU cycles, even on the vast majority of
applications that do not use it.

-- 
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] SQLite 3.20.0 postponed

[petern]

Indeed.  Or Type(T) of long, or sqlite_int64, or whatever is most universal
where porting other architectures is concerned. It would be a shame if the
API had to be changed later because the integer type chosen couldn't hold a
pointer.

From there, in a closed compiled host C/C++ setting with the discipline of
header files, one may simply perform the stricmp("CARRAY",(const char*) T)
cast to T string pointer comparison as desired and leave the API out of
that part.  This leaves open the more conventional test of T with enum or
#define compile time constant.

Now it remains, on the surface, that this new pseudo null pointer API
appears redundant in light of the existing BLOB interface and the
possibility of simply adding Type(T) versions of those BLOB function
signatures to the API.

How was adding to the BLOB API ruled out?  Is there a fundamental problem
with slightly broadening the BLOB API to deal with typed host objects?
Surely returning zero for the Type(T) would be backward compatible, would
it not?  Just asking.









On Fri, Jul 21, 2017 at 12:48 PM, Keith Medcalf  wrote:

> On Friday, 21 July, 2017 10:51, Richard Hipp  wrote:
>
> > But sqlite3_result_pointer() and sqlite3_bind_pointer() are not
> > invoked from those languages.  The _pointer() routines are invoked
> > from C, and C does easily support string literals that are static
> > strings.
>
> > A C-language wrapper around sqlite3_result_pointer() and
> > sqlite3_bind_pointer() that interfaces to the non-static-string
> > language can simply insert the required static string.
>
> Well, yes.  Technically.  Almost everything everywhere is called from code
> written in C.  Very little meaningful anything is written in any other
> language.  So although you may be writing something in Java (heavens
> forbid), Java was written in C.  So in the end, all calls are made from
> software written in C.  This is the way of the world.  Some people just
> like to add lots of syntactical sugar and overhead which eventually ends up
> being C code -- either translated by a preprocessor (as in the case of
> C++), or by a compiler written in C (or written in some other language that
> was written in C ... repeat for as deep down the rabbit hole as you need to
> go).  There are a few self-hosted language compilers that are exceptions,
> but not very many.  And they all started as C before they were re-written
> in themself so they could become self-hosted.
>
> However, the change does create a problem when one is using a sugary
> language (for example Python).  It does not know how to bind pointers, nor
> is there any way to pass in a variable static "string" as an extra
> parameter.  So for example, the carray extension *used* to be able to be
> passed a pointer which was bound as an int (you obtain the pointer by
> allocating a ctypes array and asking for the pointer) -- of course this is
> unsafe if you do something stupid -- but then almost everything including
> making a nice cuppa tea is unsafe if you do something stupid.
>
> I have fiddled with defining a new type for the python interface that can
> contain a string and a reference to a ctypes object (so that the string
> stays in scope and the ctypes array stays in scope as long as the outer
> object stays in scope), and then adding an addition bind detection for this
> type of object.  It works but it is far more complicated than just
> modifying the carray extension so that it will accept integers for the
> pointer (as well as pointer types).  Plus of course (sending an integer)
> works with all interfaces that can get a pointer rather than having to
> update every single possible sugary extension.
>
>
>
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.20.0 postponed

[Keith Medcalf]

On Friday, 21 July, 2017 10:51, Richard Hipp  wrote:

> But sqlite3_result_pointer() and sqlite3_bind_pointer() are not 
> invoked from those languages.  The _pointer() routines are invoked 
> from C, and C does easily support string literals that are static 
> strings.

> A C-language wrapper around sqlite3_result_pointer() and
> sqlite3_bind_pointer() that interfaces to the non-static-string 
> language can simply insert the required static string.

Well, yes.  Technically.  Almost everything everywhere is called from code 
written in C.  Very little meaningful anything is written in any other 
language.  So although you may be writing something in Java (heavens forbid), 
Java was written in C.  So in the end, all calls are made from software written 
in C.  This is the way of the world.  Some people just like to add lots of 
syntactical sugar and overhead which eventually ends up being C code -- either 
translated by a preprocessor (as in the case of C++), or by a compiler written 
in C (or written in some other language that was written in C ... repeat for as 
deep down the rabbit hole as you need to go).  There are a few self-hosted 
language compilers that are exceptions, but not very many.  And they all 
started as C before they were re-written in themself so they could become 
self-hosted.

However, the change does create a problem when one is using a sugary language 
(for example Python).  It does not know how to bind pointers, nor is there any 
way to pass in a variable static "string" as an extra parameter.  So for 
example, the carray extension *used* to be able to be passed a pointer which 
was bound as an int (you obtain the pointer by allocating a ctypes array and 
asking for the pointer) -- of course this is unsafe if you do something stupid 
-- but then almost everything including making a nice cuppa tea is unsafe if 
you do something stupid.

I have fiddled with defining a new type for the python interface that can 
contain a string and a reference to a ctypes object (so that the string stays 
in scope and the ctypes array stays in scope as long as the outer object stays 
in scope), and then adding an addition bind detection for this type of object.  
It works but it is far more complicated than just modifying the carray 
extension so that it will accept integers for the pointer (as well as pointer 
types).  Plus of course (sending an integer) works with all interfaces that can 
get a pointer rather than having to update every single possible sugary 
extension.






___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.20.0 postponed

[petern]

Yes.  Good point.  Before seeing Richard's last commits for pseudo-null
pointer passing with static string type name, I proposed that the
pseudo-null pointer API be extended with function signature forms which
pass by value a user defined integer field for type information.

After further contemplation, I think it would be better to simply add the
BLOB API function signature forms to pass optional user defined type
information (by value) to achieve two factor pointer type identification.
One can already test BLOB byte length.  Adding an optional field to
communicate explicit type id would truly rule out the possibility of
dereferencing a nonsense BLOB which happens to be the same length in bytes
as the expected host object.



On Fri, Jul 21, 2017 at 9:03 AM, Gwendal Roué 
wrote:

>
> > Le 21 juil. 2017 à 17:55, Gwendal Roué  a écrit
> :
> >
> > First, this strcmp() give a lot of work to languages that wrap SQLite
> and lack support for "static strings". Building a global \0-terminated
> buffer that never gets deallocated is not always that easy :-)
>
> For the record, here is the commit that brings support for SQLite 3.20.0 :
> https://github.com/groue/GRDB.swift/commit/0a603f1be3966d478b505373af95d2
> 57224ce5b0  0a603f1be3966d478b505373af95d257224ce5b0>
>
> The context is custom FTS5 tokenisers for Swift:
> https://github.com/groue/GRDB.swift/blob/v1.2.2/
> Documentation/FTS5Tokenizers.md  GRDB.swift/blob/v1.2.2/Documentation/FTS5Tokenizers.md>
>
> Gwendal
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.20.0 postponed

[Richard Hipp]

On 7/21/17, Gwendal Roué  wrote:
>
> First, this strcmp() give a lot of work to languages that wrap SQLite and
> lack support for "static strings".

But sqlite3_result_pointer() and sqlite3_bind_pointer() are not
invoked from those languages.  The _pointer() routines are invoked
from C, and C does easily support string literals that are static
strings.

A C-language wrapper around sqlite3_result_pointer() and
sqlite3_bind_pointer() that interfaces to the non-static-string
language can simply insert the required static string.

We do not want the static string to be a parameter to a generic
higher-level interface.  That defeats the purpose of the static
string.  Remember, the string is a "pointer type".  We do not want to
support interfaces that provide access to pointers of any type the
user wants.  We are not trying to recreate C++ templates or other
interfaces that work with arbitrary types.  Each use of _pointer() is
intended to be used for a single narrowly defined purpose.

-- 
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] SQLite 3.20.0 postponed

[Gwendal Roué]

> Le 21 juil. 2017 à 17:55, Gwendal Roué  a écrit :
> 
> First, this strcmp() give a lot of work to languages that wrap SQLite and 
> lack support for "static strings". Building a global \0-terminated buffer 
> that never gets deallocated is not always that easy :-)

For the record, here is the commit that brings support for SQLite 3.20.0 : 
https://github.com/groue/GRDB.swift/commit/0a603f1be3966d478b505373af95d257224ce5b0
 


The context is custom FTS5 tokenisers for Swift: 
https://github.com/groue/GRDB.swift/blob/v1.2.2/Documentation/FTS5Tokenizers.md 


Gwendal

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.20.0 postponed

[Gwendal Roué]

> Le 17 juil. 2017 à 20:54, Richard Hipp  a écrit :
> 
> The 3.20.0 release will be delayed.  Some concerns came up over the
> new sqlite3_value_pointer() interface.  Interface chagnes were made
> over the weekend.  But there are still concerns.  So the decision has
> been made to back off and give the current design a few weeks to soak
> before trying to press forward with a release which will commit us to
> a particular design.
> 
> The draft website is still up at https://sqlite.org/draft - note that
> the change log at https://sqlite.org/draft/releaselog/3_20_0.html now
> identifies three (obscure) backwards compatibility breaks.  Your input
> on these changes is requested.

Hello,

When I read the documentation for sqlite3_bind_pointer, I read:

> The T parameter should be a static string

The reason is pretty clear: this T parameter will be used later by 
sqlite3_value_pointer, for a string comparison with strcmp(). It hence has to 
remain is memory forever - and static strings are good at that.

I could test it and make it work reliably in Swift for custom FTS5 tokenisers.

Here is my comment: I wonder if the key comparison with strcmp() is really 
necessary.

First, this strcmp() give a lot of work to languages that wrap SQLite and lack 
support for "static strings". Building a global \0-terminated buffer that never 
gets deallocated is not always that easy :-)

Next, there are techniques for building unique "keys" that hold in a machine 
word, and can simply be compared with ==. For example:

typedef void *sqlite3_pointer_key_t;   // defined in sqlite3.h
sqlite3_pointer_key_t key1 = "my_key"; // nice for debugging
sqlite3_pointer_key_t key2 = // hard core but still valid

Maybe this is considered awful practices - I'm certainly not a C expert.

And this would also force functions that use the new pointer APIs to expose 
those keys in some header (such as FTS5()). You may have chosen the current 
technique precisely because you don't want such API pollution.

What were your rationale behind this choice?

Thanks in advance,
Gwendal Roué

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.20.0 postponed

[petern]

Richard.  Here is food for thought.  Below is a contrived but realistic
example of an embedded application wire format which demonstrates some
expected extension function pointer allocations and another recent topic.

SELECT DoTrackingRecalibrate(column1,CommandPacket(column2,column3)) FROM
(VALUES
  ('Winnipeg','field36',
  (SELECT TrimCommand(column1,column2) FROM (VALUES
('field1',1.33),
('field2','radians')
))),
('Winnipeg','field37','Apogee'),
('Minneapolis','field36',
  (SELECT TrimCommand(column1,column2) FROM (VALUES
('field1',4.33),
('field2','radians')
))),
('Minneapolis','field37','Perigee')
)
GROUP BY column1;

DoTrackingRecalibrate() is an ordinary extension function wrapping a host
function.  It takes arguments of a TEXT value and a BLOB pointer, the
output of host object wrapper CommandPacket().  CommandPacket() and
TrimCommand() are both aggregate extension functions which allocate their
underlying host object on the first step and supply a destructor callback,
on the final step, to sqlite3_result_blob().

This SQL embodies both sending the two commands and the complete
storage/wire format if these exact commands must be marshaled remotely or
stored for playback.  One of the strengths of SQLite is how it can support
a straightforward and portable serialization format like this.

This example also demonstrates a natural and convenient pattern for
expressing initialization values of host objects nested to arbitrary
depth.  Notice here how introducing WITH clauses to name the initialization
value columns would produce redundant table names and unintuitive statement
order.

Now I'll go a bit further with a suggestion.  Consider the improvement in
clarity and readability of this wire format after a minor change in VALUES
clause syntax to directly specify column names.  Here I'll introduce a
hypothetical AS sub-clause but any other proposal which affords specifying
column names within the VALUES clause scope would work equally well.

Hypothetically naming columns thusly:

   VALUES (),()...  AS ("colname1","colname2",..."columnN")

The above example can now read even more clearly and intuitively as follows.

SELECT DoTrackingRecalibrate(node,CommandPacket(packetField,packetValue))
FROM (VALUES
  ('Winnipeg','field36',
  (SELECT TrimCommand(trimField,trimValue) FROM (VALUES
('field1',1.33),
('field2','radians')
AS ("trimField","trimValue",
('Winnipeg','field37','Apogee'),
('Minneapolis','field36',
  (SELECT TrimCommand(trimField,trimValue) FROM (VALUES
('field1',4.33),
('field2','radians')
AS ("trimField","trimValue",
('Minneapolis','field37','Perigee')
AS ("node","packetField","packetValue"))
GROUP BY node;



On Mon, Jul 17, 2017 at 11:54 AM, Richard Hipp  wrote:

> The 3.20.0 release will be delayed.  Some concerns came up over the
> new sqlite3_value_pointer() interface.  Interface chagnes were made
> over the weekend.  But there are still concerns.  So the decision has
> been made to back off and give the current design a few weeks to soak
> before trying to press forward with a release which will commit us to
> a particular design.
>
> The draft website is still up at https://sqlite.org/draft - note that
> the change log at https://sqlite.org/draft/releaselog/3_20_0.html now
> identifies three (obscure) backwards compatibility breaks.  Your input
> on these changes is requested.
>
> The "prelease snapshot" on https://sqlite.org/download.html is
> up-to-date for people who want to try out the new code.  Please do so.
> Report any concerns here or via direct email to me.
>
> I will try provide a write-up on the motivations, use, and limitations
> of sqlite3_value_pointer() soon.
>
> All of the changes that where queued for release on branch-3.20 are on
> trunk.  Development will continue on trunk until we restart the
> release cycle.
>
> The check-list (https://www.sqlite.org/checklists/320/index) has
> been reset to its initial state.  It will start over again in a week
> or two.
>
> --
> 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
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users