RDB$BLOB_UTIL system package.

[asfernandes]

[aafemt]

Wouldn't it be better for this package to be a little more compatible with Oracle in term of names and usage...?

[dyemanov]

I've added some comments with a hope to close the remaining questions. Naming consistency (whether "_BLOB" suffix in method names should be mandatory) also needs some agreement.

[asfernandes]

This package needs some adjustments after APPEND_BLOB to not implement same thing in different way:

• Currently RDB$BLOB_UTIL.NEW returns a handle, that needs usage of RDB$BLOB_UTIL.APPEND and RDB$BLOB_UTIL.MAKE_BLOB.

RDB$BLOB_UTIL.NEW should be replaced by RDB$BLOB_UTIL.NEW_BLOB, that creates (only create, not append) a blob in very similar way than APPEND_BLOB do, but with option to create it in temporary space and segmented/stream like RDB$BLOB_UTIL.NEW was allowing.

• RDB$BLOB_UTIL.APPEND and RDB$BLOB_UTIL.MAKE_BLOB should be removed and let APPEND_BLOB and BLB_close_on_read do this work.

• RDB$BLOB_UTIL.CANCEL should be adapted in relation to changed RDB$BLOB_UTIL.NEW. It should be split in two functions: RDB$BLOB_UTIL.CLOSE (for opened handles) and RDB$BLOB_UTIL.CANCEL_BLOB (for BLB_close_on_read).

Please note that some functions has _BLOB suffixes and some not. This is because some functions operates on blobs and some in handles.

Maybe make sense to add _HANDLE suffixes too. That would also be to deal with reserved words, as for example, CLOSE is a reserved word.

[sim1984]

I do not agree with these changes. Why try to cast the return result to the RDB$BLOB_APPEND variant? Let this package work with handles and in a different way than RDB$BLOB_APPEND.

[asfernandes]

I do not agree with these changes. Why try to cast the return result to the RDB$BLOB_APPEND variant? Let this package work with handles and in a different way than RDB$BLOB_APPEND.

Cast RDB$BLOB_APPEND? I said to remove RDB$BLOB_UTIL.APPEND. This job can be done by APPEND_BLOB, we liking it or not.

So with exception of RDB$BLOB_UTIL.NEW_BLOB (that fulfills a job not done by APPEND_BLOB), the package will be most for reading.

[sim1984]

I don't mind deleting append, but in this case it would be necessary to provide the blob_write procedure for new blobs. Let this package be a kind of analogue of the blob api. In this case, you will not be able to abandon make_blob. In addition, I am against changing the types of open. Otherwise, it will work, but here the fish was wrapped. And by the way, it would be nice to have a blob_info procedure, similar to the api, but returning all the information at once, such as the blob type, number of segments, length, and so on.

[asfernandes]

Why are you insisting for write function if APPEND_BLOB can do it?

[cincuranet]

Maybe make sense to add _HANDLE suffixes too. That would also be to deal with reserved words, as for example, CLOSE is a reserved word.

That would make sense to me.

[sim1984]

How about the BLOB_INFO procedure, which returns information about a BLOB:

• blob type (segmented, streamed)
• blob length
• number of segments (if any);
• blob placement (temporary, permanent).

[asfernandes]

How about the BLOB_INFO procedure, which returns information about a BLOB:

• blob type (segmented, streamed)

What is the use case to get this info in PSQL?

• blob length

There is already CHAR_LENGTH and OCTET_LENGTH.

• number of segments (if any);

What is the use case to get this info in PSQL?

• blob placement (temporary, permanent).

This may be good.

[sim1984]

What is the use case to get this info in PSQL?

This may be required for your own BLOB_UTILS package. BLOB navigation with SEEK is only possible for streaming BLOBs.

About length, I meant the information that can be obtained through isc_blob_info. Although considering that it still doesn't work for long BLOBs > 2GB, it's probably not necessary.

In fact, I would like only this:

• blob type (segmented, streamed)
• blob placement (temporary, permanent).

[aafemt]

This may be good.

But also useless IMHO.

Implementation of SEEK for segmented BLOBs is not that complicated.