Why does LPAD require non-empty padding when it only needs to truncate a BLOB?
00:54 09 Sep 2026

I reduced the case to the following rows before looking at the expression.

CREATE TABLE packet_archive (gateway_id STRING TAG, payload BLOB FIELD);
INSERT INTO packet_archive(time, gateway_id, payload) VALUES (1000, 'gw-east', X'00ff10');

A packet archive stores device frames as BLOB values and a summary keeps only the first two bytes. Apache IoTDB 2.0.8 table model still fails on an empty pad value when the target is shorter than the input.

Truncation with an empty BLOB as the unused pad value:

SELECT time, payload, LPAD(payload, 2, X'') AS prefix FROM packet_archive;

The server returned:

Msg: org.apache.iotdb.jdbc.IoTDBSQLException: 701: Failed to execute function 'Lpad' due the value 0x00ff10 corresponding to a empty padding string.

For comparison, I ran control with a one-byte pad value:

SELECT time, payload, LPAD(payload, 2, X'00') AS prefix FROM packet_archive;
+-----------------------------+--------+------+
|                         time| payload|prefix|
+-----------------------------+--------+------+
|1970-01-01T08:00:01.000+08:00|0x00ff10|0x00ff|
+-----------------------------+--------+------+

What I am trying to confirm:

Both queries target length 2 and only truncate 0x00ff10 to its first two bytes. A non-empty pad works, while an empty pad fails. Does LPAD validate the pad bytes before deciding whether it will pad or truncate, and should an empty pad be accepted on the truncation branch?

time-series apache-iotdb