Commented by: @AlexPeshkoff

When backup is restored isc_info_svc_line is used only for monitoring data returned by "-v" switch of gbak which is definitely nothing other than text data. Stdin data passed to service is treated as binary stream.

Commented by: @aafemt

I'm talking about send_items, not query_items.

Commented by: @pcisar

It's clear that choice to use isc_info_svc_line to mark chunk of stdin sent to service via SPB was not wise choice (to say it mildly). Both isc_info_svc_to_eof and isc_info_svc_line are normally used for service output (query items) and they were created just for that purpose. Using them to identify items going in other direction only caused this confusion. It's pointless to ask that isc_info_svc_to_eof should be supported here as well (as an alias), and it would cause only more confusion as people would expect that they would mean two different things that would work similarly as in query direction (which they can't). In fact id used to send data to restore service has no special meaning except to identify the data chunk (so no EOLN at play here etc.). It could be ANY number devs would choose. Was using svc_line logically correct? No. Changing it to proper one (by logic to isc_info_svc_stdin) would be best, but that would break all existing code. At least isc_info_svc_line has some logic we could live with, but support for isc_info_svc_to_eof alias has no logic at all.