Martijn Tonies wrote:

>> There a gobs of 64K restrictions in the server. All are historical and
>> can be eliminated, but BLR would have to be extended for 4 byte counts
>> and lengths for openers, and couple of other dozen things fixed as well.
>>
>> It would be smarter to find out why such ludicrous statements are being
>> used and extend SQL to make them unnecessary.
>>
>
> In order to be able to send blobs directly from a script.
>
>
>>> Would this make sense? I understand this is a change in the
>>> wire protocol, but it would finally get Firebird up to date with
>>> regard to sending BLOBs to the server like the SQL Standard
>>> specifies.
>>>
>>>
>>>
>> Somehow I think the SQL standard is silent about how blobs are
>> communicated between a client and the server. I agree that it would be
>> nice to allow arbitrary conversion between various types and blobs
>> (almost everyone else has them), but I don't think any change is
>> necessary to the wire protocol to support them.
>>
>
> Indeed, the SQL Standard says nothing abuot communication -- what
> I meant was that the standard allows to send (binary) blobs to the
> server from a script by using a special syntax:
>
> insert into mytable (myblob)
> values X'0101002200448AE884E0232...
>

Why would a script be sending a large blob literal? Might it not make
more sense to be able to reference a local file name in a script rather
than translate the content into hex?

> etc
>
> But given that Firebird doesn't support long SQL statements, it can
> never create this is a useful manner.
>

Don't think of the problem as "long sql statements" -- that's a
statement of a work around, not a solution. It would be better to go
back to the original problem, state it clearly, and think about the
range of alternative solutions. Jpegs, for example, are never born as
ascii representations of hex digits. There's gotta a better way than
that...