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@gmx.net


Wed, 14 May 2003 00:47:46 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Text format protocol representation
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?  :-)


14 May 2003 10:54:13 +1000
Bruce Badger <bruce_badger@badgerse.com>
Re: Text format protocol representation
Peter Eisentraut <peter_e@gmx.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

Tue, 13 May 2003 23:48:58 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Text format protocol representation 
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Peter Eisentraut <peter_e@gmx.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


18 May 2003 09:07:26 -0400
Greg Stark <gsstark@mit.edu>
Re: Text format protocol representation
Greg Stark <gsstark@mit.edu> writes:

> Tom Lane <tgl@sss.pgh.pa.us> writes:
> 
> > Peter Eisentraut <peter_e@gmx.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

19 May 2003 18:26:20 -0400
Doug McNaught <doug@mcnaught.org>
Re: Text format protocol representation
Greg Stark <gsstark@mit.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

Mon, 19 May 2003 20:07:11 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Text format protocol representation 

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Greg Stark <gsstark@mit.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


22 May 2003 10:03:19 -0400
Greg Stark <gsstark@mit.edu>
Re: Text format protocol representation
Greg Stark <gsstark@mit.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

Thu, 22 May 2003 11:38:09 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Text format protocol representation 
Tom Lane kirjutas N, 22.05.2003 kell 18:38:
> Greg Stark <gsstark@mit.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

23 May 2003 08:27:49 +0300
Hannu Krosing <hannu@tm.ee>
Re: Text format protocol representation
Hannu Krosing <hannu@tm.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

Fri, 23 May 2003 09:08:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Text format protocol representation 