> Vlad Khorsun escreveu:
>>>> Is it also ambigious with comparison operator ?
>>>>
>>>>
>>> No. We define special rule for @. What follows @ is the parameter name.
>>> But I prefer := operator.
>>>
>>
>> I also like ":=" operator but it is incosistent with our PSQL, unfortunately.
>> As for rule for @ - we don't need it there, see below
>>
> There is nothing inconsistent. It's a new operator to assign values to
> named parameters.

I.e. this is assignment operator. Is it consistent to have one assignment operator (:=)
for one purpose, and another (=) from another purposes ? I don't think so

>>>>> 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.

I mean it will work in DSQL as before

>> Yes. But how it related to the our question ? Also i suggest not allow to mix named and unnamed
>> parameters at one query.
>>
> And it's not good to have different syntax regarding named/unnamed
> parameter is used inside the exec. stmt. string.

EXEC STMT will use named parameters only. At least at first implementation. And this named
parameters wouldn't been implemented at DSQL level. As we allow to call EXEC STMT from
PSQL only i see no problem with compatibility in future.

Please, don't make generic statements, show examples when possible. Else we never
understand each other.

>>>> 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.
>>>
>>
>> Many votes - it is how many ? 10 ? Don't make me laugh ;) voting system it is good to have,
>> but 10 votes is nothing to even look at it, i'd said.
>>
> How many features has more votes than it? It was one of the more voted
> things when I looked.

Again, 10 votes is equal to no votes at all. My opinion of course. Currently i didn't consider
voting system as working\representative.

>>> 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.
>>>
>>
>> "C" language have the same issue and worked fine with it, isn't is ? Unfortunately in this
>> aspect our PSQL more like "C" than "PASCAL". And i don't think mix of two languages is
>> ok for us. Also imagine following code :
>>
>> DECLARE X BOOLEAN;
>> DECLARE A INT;
>> DECLARE B INT;
>>
>> X = A = B;
>>
>> You see - there we have same ambiguity. So introducing ":=" (or @ mark) for parameters
>> is not a solution for "BOOLEAN data type issue".
> The is no ambiguity in "X = A = B" for our language. We accept l-values
> only at statement level (and not inside expressions) and we don't accept
> expressions at statement level.

Not sure i understand what you mean above ;)

Anyway, i need to move forward. I'll implement following syntax for input parameters of EXEC STMT :

param_name = expression [, param_name = expression]

If we'll decide to change syntax it wouldn't been too hard as only parser would need to be changed

Regards,
Vlad