Re: Re: charin(), text_char() should return something else for empty input - Mailing list pgsql-hackers

From ncm@zembu.com (Nathan Myers)
Subject Re: Re: charin(), text_char() should return something else for empty input
Date
Msg-id 20010529130335.Y18121@store.zembu.com
Whole thread Raw
In response to Re: charin(), text_char() should return something else for empty input  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: charin(), text_char() should return something else for empty input  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Mon, May 28, 2001 at 02:37:32PM -0400, Tom Lane wrote:
> I wrote:
> > I propose that both of these operations should return a space character
> > for an empty input string.  This is by analogy to space-padding as you'd
> > get with char(1).  Any objections?
> 
> An alternative approach is to make charin and text_char map empty
> strings to the null character (\0), and conversely make charout and
> char_text map the null character to empty strings.  charout already
> acts that way, in effect, since it has to produce a null-terminated
> C string.  This way would have the advantage that there would still
> be a reversible dump and reload representation for a "char" field
> containing '\0', whereas space-padding would cause such a field to
> become ' ' after reload.  But it's a little strange if you think that
> "char" ought to behave the same as char(1).

Does the standard require any particular behavior in with NUL 
characters?  I'd like to see PG move toward treating them as ordinary 
control characters.  I realize that at best it will take a long time 
to get there.  C is irretrievably mired in the "NUL is a terminator"
swamp, but SQL isn't C.

Nathan Myers
ncm@zembu.com


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Plans for solving the VACUUM problem
Next
From: "Mikheev, Vadim"
Date:
Subject: RE: Plans for solving the VACUUM problem