SQLite Forum

Is the call order of functions in a statement strictly left-to-right?
Login

Is the call order of functions in a statement strictly left-to-right?

(1) By Stephan Beal (stephan) on 2020-05-01 03:37:49 updated by 1.1 [link] [source]

Hi, all,

i thought i knew this, but now have doubts...

i am implementing a UDF for the Fossil SCM for which the order of UDF calls in a given statement is important, and need to know for certain whether the functions will be called in the order they appear in the SQL, or whether they may be called in an arbitrary order?

:-?

For the curious...

The UDF references a piece of app-global state which has its own C-level cursor, the UDF is to be used something like:

```
SELECT fcard(0), -- 0 == step the internal cursor
   fcard(1), -- 1 = grab the 1st field from the current internal row
   fcard(2), -- 2nd field
   fcard(3), -- 3rd field
   fcard(4); -- 4th field
```

The UDF is not marked with `SQLITE_DETERMINISTIC`, so no calls should be optimized away.

For proper functioning, it's critical that the `fcard(0)` call be executed before the others to step the internal cursor, else the other calls would not behave properly.

Is the call order of functions in a statement strictly left-to-right?

(1.1) By Stephan Beal (stephan) on 2020-05-01 04:46:57 edited from 1.0 [link] [source]

Hi, all,

i thought i knew this, but now have doubts...

i am implementing a UDF for the Fossil SCM for which the order of UDF calls in a given statement is important, and need to know for certain whether the functions will be called in the order they appear in the SQL, or whether they may be called in an arbitrary order?

:-?

For the curious...

The UDF references a piece of app-global state which has its own C-level cursor, the UDF is to be used something like:

SELECT fcard(0), -- 0 == step the internal cursor
   fcard(1), -- 1 = grab the 1st field from the current internal row
   fcard(2), -- 2nd field
   fcard(3), -- 3rd field
   fcard(4); -- 4th field

The UDF is not marked with SQLITE_DETERMINISTIC, so no calls should be optimized away.

For proper functioning, it's critical that the fcard(0) call be executed before the others to step the internal cursor, else the other calls would not behave properly.

Edit: i have since found a nicer solution which doesn't require a UDF, but am still curious about the call order guarantees.

(2) By Larry Brasfield (LarryBrasfield) on 2020-05-01 09:25:10 in reply to 1.1 [link] [source]

I've never seen such a guarantee for any language, except for the so-called comma operator in C/C++ which pretends to be part of expression syntax. And I can say that the SQLite parser does not keep enough information, (at least not explicitly), to even permit such an ordering to be effected or assured as various expression and query optimizations are done. And, given how challenging optimization is for many other reasons, I doubt that any implementation's designer(s) would volunteer to add that ordering to the other optimization constraints.

I also have to say that your UDFs must have been more than pure functions since they must have some side effects that affect the results. In that case, what you are doing is procedural and should not be made to masquerade as an expression or query. For that reason alone, your nicer solution must also be a clearer one.

(3) By anonymous on 2020-05-01 10:45:09 in reply to 1.1 [link] [source]

Your apparently-scalar UDF doesn’t make sense IMHO, because it is inherently table-valued.

Write a proper table valued function, perhaps returning a single row, and (cross) join on it,
as usual, to “step” it. No ordering issue then!

(5) By Stephan Beal (stephan) on 2020-05-01 11:15:48 in reply to 3 [link] [source]

Your apparently-scalar UDF doesn’t make sense IMHO, because it is inherently table-valued.

That was actually my first thought, but the infrastructure overhead appeared somewhat overkill for the task at hand.

(4) By Richard Hipp (drh) on 2020-05-01 11:00:41 in reply to 1.1 [source]

No such guarantee

It happens to work that way now, but that is merely an accident of the implementation and might change at any moment.