From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: patch for passing the cts |
Date: | 2005-06-15 10:45:04 |
Message-ID: | 379C1838-A611-4DB0-92D5-EF78C2FCFB1E@fastcrypt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2005-06-15 13:37:09 | Re: patch for passing the cts |
Previous Message | Oliver Jowett | 2005-06-15 04:46:09 | Re: patch for passing the cts |