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