You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following code worked in 23.3 and is parsed correctly by db* CODECOP:
create or replacefunctionget42 return number is
mle language javascript q'[return 42;]';
/select get42();
However, this code does not work in 23.4. anymore. The syntax for Inline MLE Call Specification changed in 23.4 in an incompatible way. In 23.3 a string was expected. A normal string or a q-quoted string. Now the 23.4 delimiters for the JS code can be freely chosen. However, a q-quoted string is not applicable anymore. The same character sequence must be used for the start and the end delimiter. Exceptions are the pairs (), [], {} and <>.
In 23.4 the following code works (it's using a single apostrophe as start/end delimiter) and it parsed correctly by db* CODECOP since it is treating the script body as an ordinary string.
create or replacefunctionget42 return number is
mle language javascript ' return 42;';
/select get42();
However, we get parser errors when using other delimiters like in the following examples:
create or replacefunctionget42 return number is
mle language javascript (( return 42; ));
/create or replacefunctionget42 return number is
mle language javascript [[ return 42; ]];
/create or replacefunctionget42 return number is
mle language javascript {{ return 42; }};
/create or replacefunctionget42 return number is
mle language javascript << return 42; >>;
/create or replacefunctionget42 return number is
mle language javascript $$ return 42; $$;
/create or replacefunctionget42 return number is
mle language javascript $code$ return 42; $code$;
/
The script body should be treated similarly to conditional compilation blocks. It should accept any tokens. It might be difficult to support all types of delimiters with the current parser technology, but a chosen set of delimiters, similar to q-quoted strings, should be doable.
In the amended Oracle documentation the preferred delimiters are double curly braces. This means for start {{ and for the end }}. The grammar should support at least this delimiters.
The text was updated successfully, but these errors were encountered:
The following code worked in 23.3 and is parsed correctly by db* CODECOP:
However, this code does not work in 23.4. anymore. The syntax for Inline MLE Call Specification changed in 23.4 in an incompatible way. In 23.3 a string was expected. A normal string or a q-quoted string. Now the 23.4 delimiters for the JS code can be freely chosen. However, a q-quoted string is not applicable anymore. The same character sequence must be used for the start and the end delimiter. Exceptions are the pairs
()
,[]
,{}
and<>
.In 23.4 the following code works (it's using a single apostrophe as start/end delimiter) and it parsed correctly by db* CODECOP since it is treating the script body as an ordinary string.
However, we get parser errors when using other delimiters like in the following examples:
The script body should be treated similarly to conditional compilation blocks. It should accept any tokens. It might be difficult to support all types of delimiters with the current parser technology, but a chosen set of delimiters, similar to q-quoted strings, should be doable.
In the amended Oracle documentation the preferred delimiters are double curly braces. This means for start
{{
and for the end}}
. The grammar should support at least this delimiters.The text was updated successfully, but these errors were encountered: