The argument value was presented as just a plain value before (just integers in the last examples). Having such plain values causes a limitation. The user has to state precisely what the value is. It cannot be evaluated during the query execution.
Having the arguments to be calculated as a result of a subquery makes them more flexible. The user may specify a subquery as complex as he or she wants. The previous example should look as follows:
SELECT * FROM jelly(,'SELECT 2') AS j1, jelly(,'SELECT 3') AS j2, other_relation WHERE j1.first > 4, j2.first < 5 ;A subquery which appears as the argument of the Jelly Views may be as complex as necessary, but its result has to be a single column. Such a subquery may pass not only a single value to the goal, but also a set of values instead, which makes the system even more flexible. For example:
SELECT * FROM jelly(,'SELECT id FROM other_relation') ;Therefore, the second parameter for the goal of the Jelly View jelly is taken as a set of all values of id attribute of relation other_relation. In other words, the state of jelly may contain, in the second column, id values taken from other_relation only. Values in the first column are unbounded and they will be inferred.
Igor Wojnicki 2005-11-07