|Subject||Re: [Firebird-Architect] Global Temporary Tables|
> > If blob stored initially in one page space and assigned to relation fromNo, this is not required to set bpb. This bpb extension useful for that
> >another page space then we must copy blob into another page space and
> >release pages from first page space. Proposed bpb extension allow user
> >to avoid such copying - if user already know that blob will be assigned to
> >temporary table then he can point engine to allocate blob in temporary page
> >space at creation time.
> Yes, it would be nice if an application program were to declare that a
> blob is to go into temporary space, but given that the whole idea of
> temporary tables is that they are transparent to the application layer
> and tools, requiring applications and tools to take special actions just
> isn't going to fly.
application which needed it. All other can run unchanged.
> How are you going to do when somebody tries toNo, i'll just copy blob into appropriate page space when it materialized.
> assign the wrong type of blob, throw an error?
> The most common case is that data containing blobs will be copied fromYes
> permanent tables into a temporary table. In this case, you have no
> choice but to copy the blob.
> So that leaves the far fetched case thatApplication which imports some info (documents in different forms) into GTT
> somebody does inserts containing blobs into temporary tables that we're
> quibbling about. Can you come up with a scenario where somebody would
> ever do that? If not, why even worry about it -- copy the blob and get
> one with life.
then parse temporary blobs (on the server side) and store it in persistent
in another (normalized) format ? This is just example, not a real application ;)