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

I also like ":=" operator but it is incosistent with our PSQL, unfortunately.
As for rule for @ - we don't need it there, see below

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

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

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

Regarsd,
Vlad