QueryProcessorにおいて、ストレージエンジンにscanさせるとき、Recordからエイリアス情報が失われている about apllodb HOT 7 CLOSED

Record, ImmutableRow に FFR (や TCR) を持たせる構成だと、「SELECTの（aliasがある）ときだけFFRにエイリアスをセット」ということが型レベルで守られない。

Record, ImmutableRow はシンプルな Vec にしてカラムのラベル情報は持たず、

FieldIndex -> Set<FullFieldReference> -> (TableName, ColumnName) -> Schema -> 添字

という解決pathを通るのが良いんじゃないかな

from apllodb.

FFRは、本来DMLにしか出てこないもの（エイリアスが存在するのはDMLなので）。
そう考えると query-processor にFFRを閉じ込める発想も出てくるが、Recordがinstantiateされた段階でFieldIndexによるgetをしたいのも事実。

from apllodb.

RecordIterator を read 専用にした上で、

• RecordIterator が Vec を持つ
• RecordはRecordIterator中の Vec を参照する
• Record::get(FieldIndex) において、Vec の添字が解決される
• Recordの内部構造の添字が↑に一致

という感じでgetを実現するかな

from apllodb.

ExpressionがFFRを持つのは良いのか。

INSERT INTO t (id, c1, c2) SELECT t2.t_id, t2.c1 * 100, t2.c2 FROM s AS t2;

UPDATE t AS t1 set c1 = t1.c2 * 5;

みたいなSQLもあるから、ExpressionにはFFR持たせるべき。

from apllodb.

FFRの生成経路

SQL with Expression (DML) -> Parser -> AST -> AstTranslator

のみ。

Recordの生成経路

SELECT -> ... -> RecordIterator -> Record

のみ。read-only。

INSERTようには別途ValueList的なものを作ってあげる。

from apllodb.

クソデカリファクタになるので...

作業ロードマップ

1. INSERT用に使う構造をRecordじゃないやつにする。ただし、 INSERT ... SELECT に将来対応できるよう、Recordからの変換余地は残す。
2. Record / RecordIterator 改造
3. ImmutableRow / SqliteRowIterator 改造
4. FFR::new の禁止

from apllodb.

Record / RecordIterator 改造
ImmutableRow / SqliteRowIterator 改造

を分けて取り組むと、RowIter -> RecordIter の変換で余計なロジックを書く必要があるので、これは一緒くたに取り組むしかなさそう

from apllodb.