|Subject||Re: [Firebird-Architect] Exec. statement parameters|
> Vlad Khorsun escreveu:I also like ":=" operator but it is incosistent with our PSQL, unfortunately.
>>> 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.
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:Yes. But how it related to the our question ? Also i suggest not allow to mix named and unnamed
>>> 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.
parameters at one query.
>> So i still prefer EXEC STMT <sql> (param1 = expr1, ... ) syntax without any additionalMany votes - it is how many ? 10 ? Don't make me laugh ;) voting system it is good to have,
>> 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.
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"C" language have the same issue and worked fine with it, isn't is ? Unfortunately in this
> boolean type.
> And result of "something = otherthing" should be a valid expression
> (value) returning TRUE/FALSE/NULL.
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".