Re: patch for passing the cts

Dave Cramer wrote:

> Do you have any suggestions ?

Also, the parser for {call} is going to have to get a lot smarter. A
first cut at what it needs to do..

Extract this information from the query:

- Name of the called function
- Number of ? parameter placeholders
- Text of each function argument
- Mapping from parameter index to function argument (many-to-one)
- Eligibility of each parameter for being an OUT parameter (this can be
determined from the text the parameter maps to -- if it's a bare "?"
then it's eligible)

On execute, you reassemble a query from the IN function arguments text only.

e.g. for the query "{call f(?+?,?)}" you'll get:

 function = "f"
 3 parameters
 2 function arguments:
   argument 1 = "?+?"
   argument 2 = "?"
 parameter 1 maps to function arg 1 and can't be OUT
 parameter 2 maps to function arg 1 and can't be OUT
 parameter 3 maps to function arg 2 and can be OUT

If you set all 3 parameters as IN parameters, it assembles a SELECT
including all function arguments:

  "select * from f(?+?,?) as result"

and gives it to the query executor which executes:

  "select * from f($1+$2,$3) as result"

If you set parameter 3 to OUT, it excludes the corresponding function
argument (argument 2) when assembling the SELECT:

  "select * from f(?+?) as result"

resulting in the actual query:

  "select * from f($1+$2) as result"


Hmm.. perhaps you could get a similar effect by doing the normal query
fragmentation then stripping a comma (only) from one of the adjacent
fragments to an OUT parameter, then merging the two adjacent fragments
as you remove the parameter; but that seem pretty hairy..

-O