> From: "Dimitry Sibiryakov" <SD@...>
> On 31 May 2004 at 14:49, Ivan Prenosil wrote:
>
> >In EmbeddedSQL or in FB API you can request invoking
> >blob filter by specifying both FROM and TO sub_types.
> >The CAST syntax allows to specify only one sub_type,
> >that is why I do not like such solution.
>
> So, you prefer crash that you described below?

I did not described or experienced any crash regarding using blob filters.
And you ?

>
> >IMHO blob's sub_type specified in column definition
> >is just recommendation (exactly as blob's segment size).
>
> IMHO, it is a design flaw. Server must enforce type of stored data.
> I don't want to guess what Jim was thinking about, designing BLOB
> filtering (if it was him).

I do not see any reason why to enforce such arbitrary limitations.

What if I want to store any type of file in blob field, and be able
to call different blob filters (e.g. to convert jpg->png, jpg->bmp, jpg->tif,
wav->mp3, compress/decompress any file, encrypt/decrypt any file, etc.)
With your proposal I would have to create special column
for every possible blob sub-type. Absurd.

In the past people already asked whether they can store blobs
of different subtypes in single blob column.

>
> >> As you can't store string
> >> into integer field, you can't store different subtype of BLOB.

You are mixing types and subtypes.
And if I want, I can store strings of different subtypes (i.e. charsets)
into none-charset column.

> >
> >Are you sure ?
>
> I know that currently it is not true. Engine don't care about type
> of BLOB at all.
>
> >So what do you think will happen when you have blob column
> >defined with sub_type -1, and when reading it you will request
> >to use blob filter from -2 to -3 sub_type (which is allowed in
> >ESQL or FBAPI) ?
>
> Big badaboom. And you still insist on specifying both FROM/TO
> subtypes?

No badaboom here. But even if there is some bug, why not just fix it
instead of introducing some restrictions ?

>
> >> Yes, I think that creating
> >> temporary BLOB is a proper way to go.
> >
> >Why not, if it will be properly documented.
>
> Especially if this temporary BLOB to be created in memory or
> temporary space.
>
> >Currently coercion works for sqltypes only, not for sqlsubtypes.
>
> This is result of not enforcing subtype. Engine isn't sure what
> data is stored in BLOB and don't take responsibility of converting
> it.

Is not blob usually defined as type that contains data server does not care about?

>
> >It is not possible to use coercion mechanism to request
> >transliteration of field's charset (that is stored as subtype in
> >xsqlvar).
>
> And you can provide any good reason for this inability?

I would prefer if it was possible, but currently it is not
(because of the way how connection charset is implemented).


----
Also, IIRC, Jim said that original architecture allowed blob filters
to reside anywhere between client and server (i.e. not necessarily
on server machine). It is apperently not possible anymore,
but if this functionality was restored, creating auxiliary blobs
could cause unnecessary ping-pong of blob data between machines.

>
> SY, Dimitry Sibiryakov.

Ivan