Re: Text format protocol representation

What's the rationale for not including the trailing zero byte in the
protocol representation of the text format? The output functions of data
types generate one, and the client most likely wants one, so it seems
unreasonable that the protocol cuts it out and the client has to put it
back. Is the bandwidth saved worth the extra computation?

--
Peter Eisentraut peter_e(at)gmx(dot)net

On Wed, 2003-05-14 at 08:47, Peter Eisentraut wrote:
> What's the rationale for not including the trailing zero byte in the
> protocol representation of the text format? The output functions of data
> types generate one, and the client most likely wants one, so it seems
> unreasonable that the protocol cuts it out and the client has to put it
> back. Is the bandwidth saved worth the extra computation?

I maintain the Smalltalk PostgreSQL driver. Smalltalk does not require
special terminator characters in Strings, so for me, if the extra
character gets added to the end, I have to strip it off.

So, why expend badwidth *and* computation on this? :-)

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> What's the rationale for not including the trailing zero byte in the
> protocol representation of the text format?

History, mostly --- we have not done it in the past.

> The output functions of data
> types generate one, and the client most likely wants one, so it seems
> unreasonable that the protocol cuts it out and the client has to put it
> back. Is the bandwidth saved worth the extra computation?

Those two considerations seem about a wash to me. So I'm willing to bow
to backwards compatibility as the deciding factor. Do you have a fourth
or fifth issue to put into the argument?

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > What's the rationale for not including the trailing zero byte in the
> > protocol representation of the text format?
>
> History, mostly --- we have not done it in the past.

nuls in strings aren't allowed, eh? Is there any possibility that nuls in
strings will be supported at some time in the future?

--
greg

Greg Stark <gsstark(at)mit(dot)edu> writes:

> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > > What's the rationale for not including the trailing zero byte in the
> > > protocol representation of the text format?
> >
> > History, mostly --- we have not done it in the past.
>
> nuls in strings aren't allowed, eh? Is there any possibility that nuls in
> strings will be supported at some time in the future?

What's wrong with using "bytea" for binary data?

-Doug

Greg Stark <gsstark(at)mit(dot)edu> writes:
> nuls in strings aren't allowed, eh? Is there any possibility that nuls in
> strings will be supported at some time in the future?

Not much. Use bytea if you want to store binary data.

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > nuls in strings aren't allowed, eh? Is there any possibility that nuls in
> > strings will be supported at some time in the future?
>
> Not much. Use bytea if you want to store binary data.

Oh, I don't. I was just mentioning that if you append a nul in the protocol
and allow applications to use that instead of the length provided then you've
pretty much committed to never allowing nuls in text/varchars.

[Incidentally, nul is not the same concept as NULL, don't mix the two]

--
greg

Greg Stark <gsstark(at)mit(dot)edu> writes:
> Oh, I don't. I was just mentioning that if you append a nul in the protocol
> and allow applications to use that instead of the length provided then you've
> pretty much committed to never allowing nuls in text/varchars.

Um. Well, there isn't any such assumption in the protocol (and I'm agin
Peter's suggestion to put one in), but realistically I don't see us ever
allowing \0 in external-text-representation strings. It would break too
many things on both client and server sides, and the payback is too small.

The cases I can think of where you'd like to allow \0 are really binary
data, not text, and we now have respectably clean support for binary
I/O. So the need to allow it seems to me to have dropped way down, too.

regards, tom lane

Tom Lane kirjutas N, 22.05.2003 kell 18:38:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > Oh, I don't. I was just mentioning that if you append a nul in the protocol
> > and allow applications to use that instead of the length provided then you've
> > pretty much committed to never allowing nuls in text/varchars.
>
> Um. Well, there isn't any such assumption in the protocol (and I'm agin
> Peter's suggestion to put one in), but realistically I don't see us ever
> allowing \0 in external-text-representation strings. It would break too
> many things on both client and server sides, and the payback is too small.
>
> The cases I can think of where you'd like to allow \0 are really binary
> data, not text, and we now have respectably clean support for binary
> I/O.

I know about the /O part but what about I/ ?

Are \0's handled cleanly in INSERT statements ?

Or can new protocol send binary bind variables for prepared statements ?

> So the need to allow it seems to me to have dropped way down, too.

-------
Hannu

Hannu Krosing <hannu(at)tm(dot)ee> writes:
> Are \0's handled cleanly in INSERT statements ?

Not unless escaped.

> Or can new protocol send binary bind variables for prepared statements ?

Yes.

regards, tom lane