> Vlad Khorsun escreveu:
> >> So here examples with my preferred syntax for boolean datatype,
> >> parameters in EXEC. STMT and named parameters for SPs.
> >> I didn't even put examples of DSQL named parameters.
> >>
> >
> > I don't agree with your EXEC BLOCK changes.
> >
> Sorry, it were not my intention. Just forget the question marks. ;-)

Ah, very well :)

> >> Please try to reproduce this code with your syntax. You will see how
> >> ambiguous and confusion it is (will be, when all constructions are
> >> available).
> >>
> >> -------------
> >> -- procedure p(i boolean);
> >>
> >> -- should be valid
> >> execute block (
> >> i integer
> >> ) returns (
> >> o boolean
> >> )
> >> as
> >> begin
> >> select a = c from t where a = :i into :o;
> >> execute procedure p(i = 1);
> >> end;
> >>
> >
> >
> > execute block (
> > i integer = ?
> > ) returns (
> > o boolean
> > )
> > as
> > begin
> > select a = c from t where a = :i into :o;
> > execute procedure p(i = 1);
> > end;
> >
> > I see no problem here
> >
> Data type of P(i) should not interfere in the parser.
> So you don't know, if you're assigning 1 to P(i) or is calling p with
> result of boolean expression (i = 1).

Agreed, here we have a problem

> >> -- should be valid
> >> execute block (
> >> i integer
> >> ) returns (
> >> o boolean
> >> )
> >> as
> >> begin
> >> execute statement 'select a = c from t where a = ?' (i) into :o;
> >> end;
> >>
> >
> > execute block (
> > i integer = ?
> > ) returns (
> > o boolean
> > )
> > as
> > begin
> > execute statement 'select a = c from t where a = :x' (x = i) into :o;
> > end;
> >
> >
> > Again, no problem
> >
> You changed the example. Unnamed parameter should be supported in EXEC.
> STMT, but no real problem for this statement, but...

No, i not changed it. I just show how it would be written by user.
EXEC STMT will turn it into 'select a = c from t where a = ?' as our DSQL expected.

> >> -- should be valid
> >> execute block (
> >> i integer
> >> ) returns (
> >> o boolean
> >> )
> >> as
> >> begin
> >> execute statement 'select a = c from t where ? is true' (i = 1) into :o;
> >> end;
> >>
> >
> > execute block (
> > i integer = ?
> > ) returns (
> > o boolean
> > )
> > as
> > begin
> > execute statement 'select a = c from t where :x is true' (x = i = 1) into :o;
> > -- or
> > execute statement 'select a = c from t where :x is true' (x = (i = 1)) into :o;
> > end;
> >
> > There is chance for ambiguity in x = i = 1 expression
> >
> You changed example here too, and it's more ambiguous, with unnamed
> parameter.

The same as above : DSQL will execute 'select a = c from t where ? is true'

> >> -- should be valid
> >> execute block (
> >> i integer
> >> ) returns (
> >> o boolean
> >> )
> >> as
> >> begin
> >> execute statement 'select a = c from t where a = :i' (i := i) into :o;
> >> execute procedure p(i := i = 1);
> >> end;
> >>
> >
> > execute block (
> > i integer = ?
> > ) returns (
> > o boolean
> > )
> > as
> > begin
> > execute statement 'select a = c from t where a = :i' (i = i) into :o;
> > execute procedure p(i = i = 1);
> > -- or
> > execute procedure p(i = (i = 1));
> > end;
> >
> > Same as above
> >
> And you see, you have "i" in the same expression... One refer to local
> variable, and another to the parameter, that is in another "layer" (it
> is not something of the current PSQL block).

Yes. All i may said here - don't do it :) Parser (not human) have no problem
with this example :)

...

> > You not answer on my question :
> >
> > why "x = a = b" is not ambiguous in PSQL block of code
> > but is ambiguous in EXEC STMT input parameter syntax ?
> >
> It's not ambiguous if you have only named parameters. But this should
> not be accepted, because:
> 1) EXEC. STMT. should also support our only current valid syntax of
> parameters (i.e. unnamed)

Am i already answered on this at lines above ?

> 2) you can't make procedure call syntax only with named parameters, as
> it already exists with unnamed parameter syntax.

Yes, this is the problem as shown at first example.

> > If we decide both examples are ambuguois then we will fail to introduce support
> > of boolean expressions or will force users to use := for assignment (or == for comparison).
> > If we decide both are not ambuguois then no problems except of not very clear look
> > of expressions like x = a = b = c = d, which have workaround with brackets :
> > x = ((a = b) = (c = d))
> If you consider my requirements (1) and (2), and uses (:=), there is no
> ambiguity at all, considering our language will not have assignment
> inside expressions (i.e. "a = b = c" assign value of "c" to "a" and "b").

Hmm... you almost convinced me by the first example. But i still prefer to not use ":=" as
it is well known assignment operator and we want to show there is no assignment (in usual
meaning) when we calling dynamic statement or procedure...

Regards,
Vlad