Vlad Khorsun escreveu:

>> Alex Peshkov escreveu:
>>
>>>> Don't introduce ambiguities with boolean expressions, please. :-)
>>>>
>
> Hmm... our assignment and comparison operators already ambigious, isn't is ?
>

We do not have boolean expressions (i.e. datatype).

>
>>> EXECUTE STATEMENT S (a(CURRENT_TRANSACTION), b(CURRENT_CONNECTION));
>>>
>>> Does this look better for you?
>>>
>> No, this is ambiguous with function call syntax.
>>
>> I think something more or less:
>> EXECUTE STATEMENT S (@a = CURRENT_TRANSACTION, @b = CURRENT_CONNECTION);
>>
>
> Is it also ambigious with comparison operator ?
>

No. We define special rule for @. What follows @ is the parameter name.
But I prefer := operator.

>
>
>> would be ok. And I also want a syntax that could be used to call procedures:
>> select * from sp(@p1 = 1, @p2 = 2)
>>
>> But @ is used to denote client parameters in ADO.NET. I think we need
>> opinions if this could cause problems.
>>
>
> Why do we need @ mark here ? For dynamic statement\procedure\function invokation
> we have a strict rule : left operand (of "=" operator) is always parameter name. It allow us
> to always understand what is written there. Where i am wrong ?
>

You have said unnamed (question mark) parameter is/will be allowed.

> So i still prefer EXEC STMT <sql> (param1 = expr1, ... ) syntax without any additional
> parameter markers or ":=" operators. It is very consistent with our existing syntax.

We have in our tracker (with many votes, BTW), request for boolean datatype.

That means one could have a function parameter or a variable using
boolean type.

And result of "something = otherthing" should be a valid expression
(value) returning TRUE/FALSE/NULL.


Adriano