Thread: Text format protocol representation

Text format protocol representation

From
Peter Eisentraut
Date:
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



Re: Text format protocol representation

From
Tom Lane
Date:
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


Re: Text format protocol representation

From
Bruce Badger
Date:
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?  :-)



Re: Text format protocol representation

From
Greg Stark
Date:
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



Re: Text format protocol representation

From
Doug McNaught
Date:
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


Re: Text format protocol representation

From
Tom Lane
Date:
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


Re: Text format protocol representation

From
Greg Stark
Date:
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



Re: Text format protocol representation

From
Tom Lane
Date:
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


Re: Text format protocol representation

From
Hannu Krosing
Date:
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


Re: Text format protocol representation

From
Tom Lane
Date:
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