Vlad Khorsun escreveu:

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

It's inconsistent to use (=) here, as the purposes is different.

When you use (:=), you are assigning to something in another "layer" (a
calling procedure/function parameter or a named parameter).

(=) is used to compare and assign in the same PSQL module.

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

It seems you're not planning this feature good enough. You first said it
named and unnamed parameters is (already?) available... And...

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

... are creating a different parameter mechanism that work only for EXEC
STMT, and the current existing one will not work for EXEC STMT.

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

Examples of ambiguous expressions has already posted.

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

If the voting system is not representative is another problem.
Among the voted things, it's the more voted feature.

>
>>>> 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 ;)
>

statement:
x = a -- always assignment

expression:
where x = a -- always expression
x = a = b -- a = b should always be expression with boolean
datatype

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

As long you not introduce it in the main branches, I see no problem.

One main purpose of this list is to not create features that causes
future ones to not be possible.

I see no problem in staged implementations (first named params. for
EXEC. and latter for DSQL).
But please do not think at current existing features only.

Look at other implementations too. VBA uses different operator (:= and
=). Oracle too (=> and :=).


Adriano