"One of the most painful memories I have from software, the stuff that haunts me in my dreams; is writing stored procedures for Delphi's favorite database, Interbase. Whenever you did something wrong, it would give you an error saying 'Error at BLR offset 283729' or similar, offset being the offset in the compiled code where the error supposedly happened; thereby forcing an inhuman level of discipline when making changes."
Tuesday, February 28, 2017, 11:57:10 PM, you wrote:
map> Well if we could get rid of BLR ....
> database, Interbase. Whenever you did something wrong, it would give you an
> error saying 'Error at BLR offset 283729' or similar, offset being the
bullshit. "Error at BLR offset"... is a very rare message.
And my experience says that this mostly happen with wrong or broken
So, this guy have bad memory.
Not to mention the fact that Delphi-BDE code was hiding error messages
with "try ... except end'; code, until 4.01 Read committed was
That are correct memories.
As to BLR, I don't think that eliminating BLR is a good idea. You need
to have same or better speed of interpreting SQL, for views, procedures and lot
of other objects in DB.
Until then BLR is OK.
p.s. Do not forget that MS SQL interpretes procedures in runtime,
which allows syntax errors during runtime. Do we need that?
On 01/03/2017 01:17, Dmitry Yemanov wrote:
> 01.03.2017 00:18, Dmitry Kuzmenko wrote:
>> As to BLR, I don't think that eliminating BLR is a good idea. You need
>> to have same or better speed of interpreting SQL
> Execution time does not depend on whether it's BLR or SQL. Parsing time
> (read: prepare time) depends.
A major parse time (parsing text instead of BLR) will reflect in
execution time of first execution and execution after metadata changes.
What I agree it does not make sense currently: on demand (not stored)
SQL query -> BLR -> nodes, instead of: on demand SQL query -> nodes.
SQL standard also says that when one uses "select * from", asterisk
expansion should be done in the moment the command is issued, not at
execution time. A pure stored-SQL engine will violate this rule.