вопрос из серии "то ли лыжи не едут, то ли глаз замылился"

Не могу найти в разборе FROM clause простейшего случая, который бы приводит к FROM table_name.

Ветка JOINED_TABLE обязательно приводит к сложным выражениям с обязательным JOIN,
Ветка DERIVED_TABLE - обязательный SELECT в скобках
Ветка TABLE_PROC чисто синтаксически подходит, но она приводит к обязательному созданию ProcedureSourceNode


Я посмотрел v.2.54 - та же история. И везде правило table_name дано в разделе FROM (т.е. вроде бы по месту оно имеет прямое отношение к источникам рел.данных), но не используется там вообще (поиск по тексту находит, как оно используется в других местах, но не для FROM)

Симонов Денис,
Я пытаюсь понять как устроена обработка контекстов в CompilerScratch для производных контекстов, мне это нужно для обработки нового типа контекстов. Для этого я разбираю, как и для каких рекордсорсов эти производные контексты возникают, что привело меня в parse.y. И тут я наткнулся, что не могу понять, как там простейший RelationSourceNode. Вроде всяко должно быть (как я думал), а я в упор не вижу.

Симонов Денис,
я писал тут уже
http://www.sql.ru/forum/1218402/po-sorsam-vopros?hl=
http://www.sql.ru/forum/1207166/fb3-neponyatka?hl=

Наверное я вопрос не сформулировал. Формулирую.

Правильно ли я понимаю, что в простейшем случае FROM table_name этот table_name (и вообще любое имя таблицы) будет парситься в ProcedureSourceNode?

hvlad, Спасибо

Сразу не заметил, увяз тут в "этих ваших" :) контекстах и стримах (это ж скока поллитров надо, никакое здоровье не выдержит!). Правильно я понимаю, что
1)каждому упомянутому в команде "отношению" (в самом широком смысле) в dsql-фазе ставится в соотвествие некое число "номер контекста" и там же каждое упомянутое поле привязывается к соответсвющему контексту, и все эти номера пишуться в блр?
2) на стадии pass1 отталкиваясь от того, что реально представляются "отношения", и от нумерации контекстов, строяться потоки. Если "отношение" является видом, то ему будет соотвествоваь несколько потоков. Например StoreNode::pass1Store анализирует куда мы вставляем запись, в таблицу или обновляемое представлениеи может в конце концов сгенерить несколько потоков.

Общий вопрос, из dsql-фазы в блр-фазу инфа только через блр буфер передается? Или есть какие привязанные к тому же csb структуры данных (про те же контексты), которые создаются в dsql-фазе и потом используются в блр-фазе?

... и еще один вопрос, риторический.
Вышел на ф-ию postTriggerAccess(). Вот, думаю, редкая ф-ия с развернутым комментарием, где аж 15 строк объясняют, как она работает. Читаю. В конце "код больше не соответствует этому комментарию"... ну как так то? :)