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.

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

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

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


Adriano