Почему H2 блокируется при продолжении строки '\' в хранимых процедурах?

Question

(1) Попробуйте создать встроенную хранимую процедуру с метками продолжения конца строки. Вот пример NEXT_PRIME из руководства пользователя с добавленными знаками продолжения конца строки:

DROP ALIAS IF EXISTS NEXT_PRIME;
CREATE ALIAS NEXT_PRIME AS $$ \
    String nextPrime(String value) { \
        return new BigInteger(value).nextProbablePrime().toString(); \
    } \
$$;

(2) Наблюдайте за ошибками:

Синтаксическая ошибка в операторе SQL "/org/h2/dynamic/NEXT_PRIME.java:7: недопустимый символ: \ 92 публичная статика ^ ... и т.д.

Есть веская причина, почему я задаю этот вопрос. Если бы продолжение строки было правильно поддержано в этом блоке '$$', было бы целесообразно хранить / поддерживать многострочные хранимые процедуры с обычными многострочными операторами SQL в обычном файле ресурсов строки свойств Java. Да, то, что я здесь написал, подразумевает, что обычный оператор SQL в H2 допускает просто продолжения строк. например:

//stringid=\
create table if not exists test(\
     id int,\
     name varchar,\
); 

Приведенный выше оператор SQL create, включая идентификатор строки "// stringid", может быть вырезан и вставлен из списка файлов свойств java непосредственно в консоль H2, и будет выполнен без ошибок!

Answer 1

Базы данных Java и SQL не требуют и не разрешают символы продолжения строки. Если они вам нужны по какой-либо причине, удалите их перед выполнением оператора.

Answer 2

Томас, ваш ответ хорош для Java, но не так хорош по сравнению со свойствами встроенного модуля перевода любой другой реализации хранимой процедуры SQL. Очевидно, что не следует помещать символы продолжения в модуль компиляции Java, но поскольку в SQL допускается продолжение «\», за которым следует «\ n», его следует использовать для встроенной Java Java в блоках $$. [Предположительно, знаки продолжения будут отфильтрованы перед отправкой встроенного кода в компилятор Java.]

Не является ли целью H2 быть конкурентоспособным с другими распространенными внедрениями SQL? Если так, зачем нарушать понятие SQL для единицы перевода для хранимых процедур? Синтаксис хранимых процедур варьируется в каждой реализации, но каждая реализация обрабатывает код хранимой процедуры как SQL.