Re: patch for passing the cts

Oliver,

Good observation. However aren't we back to the parsing before
register, set ?

What about making the output of the current query parser a little
more flexible, and putting some of the intelligence in the executor.

More specifically, the parser currently breaks things up into
fragments which are very easily re-assembled by the executor. Instead
use the strategy below


Dave
On 15-Jun-05, at 12:46 AM, Oliver Jowett wrote:

> 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..
Yeah, as shown, it gets ugly

>
> -O
>
>