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 <d...@sqlite.org> 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/3200000/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
