Re: Add null termination to string received in parallel apply worker

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> I was thinking about this when skimming the other StringInfo thread a
> couple of days ago. I wondered if it wouldn't be more convenient to
> change the convention that all StringInfos are null-terminated: what is
> really the reason to have them all be like that?

It makes sense for StringInfos containing text, not because the
stringinfo.c routines need it but because callers inspecting the
string will very likely do something that expects nul-termination.
When the StringInfo contains binary data, that argument has little
force of course.

I could see extending the convention for caller-supplied buffers
(as is under discussion in the other thread) to say that the caller
needn't provide a nul-terminated buffer if it is confident that
no reader of the StringInfo will need that. I'd be even more
inclined than before to tie this to a specification that such a
StringInfo is read-only, though.

In any case, this does not immediately let us jump to the conclusion
that it'd be safe to use such a convention in apply workers. Aren't
the things being passed around here usually text strings? Do you
really want to promise that no reader is depending on nul-termination?
That doesn't sound safe either for query strings or data input values.

regards, tom lane