#define true false)

https://issues.apache.org/jira/browse/SPARK-36786
Смотрите какой спип классный!

а чё именно нет?
то же INTO в селекте можно где угодно писать, например. в END LOOP сам LOOP тоже избыточный, достаточно просто END

я тупой прост

Тут либо вы хотите максимально облегчить вход для знакомых с SQL, либо вы хотите сделать язык лучше SQL то тогда зачем эти элементы синтаксиса времён кобола? Уж лучше взять какой-то ЯП или даталог в качестве основы, все будет проще

Оно

Раскрою, почему так триггернулся. Когда сделал qualify в spark SQL (чтобы запросы из терадате в реплике hdp не переписывать, конечно), на определённом этапе выяснилось, что не работает с group by без having True. И мне сразу же сказали, что с головой что-то не так у тех, кто такие запросы пишет. А ведь вполне валидный запрос. И если такие нашлись бы в источнике, то пришлось бы их переписывать, сама фича получается дискредитирована

мои пользователи не желают писать на DSL на основе JSON. хотя он простой и понятный.

transform: {
source_ds: "source",
dst_ds: "pois",
type: "Point",
lat_column: "lat",
lon_column: "lon",
default_radius: 500
}

но вот не хотят, хоть убей :(

а вотALTER source SET TYPE Point(@default.radius=500,@lat.column=lat,@lon.column=lon) INTO pois;

им почему-то кажется ближе и удобнее

причём, визуальный редактор, который позволяет процессы формочками в браузере нашлёпывать (и генерит эт самый JSON), тоже не взлетел. процессы длиной в десятки трансформаций, джойнов, и т.п. формочками это шлёпать, видимо, оч. долго

нужно именно код писать. но только не на питоне, и не на прости господи скале

ну или чё, CREATE TABLE pois (SELECT lon_column(lon) lon, lat_column(lat) lat, default_radius(500) radius, * FROM source) более SQL-но будет звучать?

На самом деле да, готовый CTAS

ну, такой синтасис очень сильно усложняет парсер, а я не готов потратить на него ещё пару месяцев

И не надо, если пользователей устраивает
Cypher, например, тоже на SQL не похож, и отлично

SQL в компактной форме компактен (странно да), а в полной достаточно выразителен, чтобы минимально ошибаться в декларировании намерений.
собственно, на выходе я хочу иметь нечто обладающее такими же свойствами. ну, плюс-минус

В какой момент MySQL понимает, что блок в undo log можно использовать повторно?

Видимо по завершению транзакции, поправьте, если не так. Хм... Неужели нет vacuum-а здесь...

Я, походу, реально дофига всего не понимаю ни в айти, ни в жизни, потому что, хоть убей, но мне не ясно, почему питон и скала - говно, а вот эти DSL-чудовища, которых Вы порождаете - это заебись. Без обид.

ну так то ты прав, эти дсл чудовища тож гавно