Vlad Khorsun escreveu:

>> So here examples with my preferred syntax for boolean datatype,
>> parameters in EXEC. STMT and named parameters for SPs.
>> I didn't even put examples of DSQL named parameters.
>>
>
> I don't agree with your EXEC BLOCK changes.
>

Sorry, it were not my intention. Just forget the question marks. ;-)

>
>
>> Please try to reproduce this code with your syntax. You will see how
>> ambiguous and confusion it is (will be, when all constructions are
>> available).
>>
>> -------------
>> -- procedure p(i boolean);
>>
>> -- should be valid
>> execute block (
>> i integer
>> ) returns (
>> o boolean
>> )
>> as
>> begin
>> select a = c from t where a = :i into :o;
>> execute procedure p(i = 1);
>> end;
>>
>
>
> execute block (
> i integer = ?
> ) returns (
> o boolean
> )
> as
> begin
> select a = c from t where a = :i into :o;
> execute procedure p(i = 1);
> end;
>
> I see no problem here
>

Data type of P(i) should not interfere in the parser.
So you don't know, if you're assigning 1 to P(i) or is calling p with
result of boolean expression (i = 1).

>
>
>> -- should be valid
>> execute block (
>> i integer
>> ) returns (
>> o boolean
>> )
>> as
>> begin
>> execute statement 'select a = c from t where a = ?' (i) into :o;
>> end;
>>
>
> execute block (
> i integer = ?
> ) returns (
> o boolean
> )
> as
> begin
> execute statement 'select a = c from t where a = :x' (x = i) into :o;
> end;
>
>
> Again, no problem
>

You changed the example. Unnamed parameter should be supported in EXEC.
STMT, but no real problem for this statement, but...

>
>
>
>> -- should be valid
>> execute block (
>> i integer
>> ) returns (
>> o boolean
>> )
>> as
>> begin
>> execute statement 'select a = c from t where ? is true' (i = 1) into :o;
>> end;
>>
>
> execute block (
> i integer = ?
> ) returns (
> o boolean
> )
> as
> begin
> execute statement 'select a = c from t where :x is true' (x = i = 1) into :o;
> -- or
> execute statement 'select a = c from t where :x is true' (x = (i = 1)) into :o;
> end;
>
> There is chance for ambiguity in x = i = 1 expression
>

You changed example here too, and it's more ambiguous, with unnamed
parameter.

>
>
>> -- should be valid
>> execute block (
>> i integer
>> ) returns (
>> o boolean
>> )
>> as
>> begin
>> execute statement 'select a = c from t where a = :i' (i := i) into :o;
>> execute procedure p(i := i = 1);
>> end;
>>
>
> execute block (
> i integer = ?
> ) returns (
> o boolean
> )
> as
> begin
> execute statement 'select a = c from t where a = :i' (i = i) into :o;
> execute procedure p(i = i = 1);
> -- or
> execute procedure p(i = (i = 1));
> end;
>
> Same as above
>

And you see, you have "i" in the same expression... One refer to local
variable, and another to the parameter, that is in another "layer" (it
is not something of the current PSQL block).

>
>
>> -- should be valid
>> execute block (
>> i integer
>> ) returns (
>> o boolean
>> )
>> as
>> begin
>> execute statement 'select a = c from t where :i is true' (i = 1) into :o;
>> end;
>>
>
> execute block (
> i integer = ?
> ) returns (
> o boolean
> )
> as
> begin
> execute statement 'select a = c from t where :i is true' (i = 1) into :o;
> end;
>
> No problems at all
>
>
>> -------------
>>
>
> You not answer on my question :
>
> why "x = a = b" is not ambiguous in PSQL block of code
> but is ambiguous in EXEC STMT input parameter syntax ?
>

It's not ambiguous if you have only named parameters. But this should
not be accepted, because:
1) EXEC. STMT. should also support our only current valid syntax of
parameters (i.e. unnamed)
2) you can't make procedure call syntax only with named parameters, as
it already exists with unnamed parameter syntax.

> If we decide both examples are ambuguois then we will fail to introduce support
> of boolean expressions or will force users to use := for assignment (or == for comparison).
> If we decide both are not ambuguois then no problems except of not very clear look
> of expressions like x = a = b = c = d, which have workaround with brackets :
> x = ((a = b) = (c = d))

If you consider my requirements (1) and (2), and uses (:=), there is no
ambiguity at all, considering our language will not have assignment
inside expressions (i.e. "a = b = c" assign value of "c" to "a" and "b").


Adriano