|Subject||Re: [Firebird-Architect] Exec. statement parameters|
> Vlad Khorsun escreveu:I.e. this is assignment operator. Is it consistent to have one assignment operator (:=)
>>>> 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.
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:I mean it will work in DSQL as before
>>>>> 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 unnamedEXEC STMT will use named parameters only. At least at first implementation. And this named
>> parameters at one query.
> And it's not good to have different syntax regarding named/unnamed
> parameter is used inside the exec. stmt. string.
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 additionalAgain, 10 votes is equal to no votes at all. My opinion of course. Currently i didn't consider
>>>> 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.
voting system as working\representative.
>>> That means one could have a function parameter or a variable usingNot sure i understand what you mean above ;)
>>> 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.
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