Skip site navigation (1) Skip section navigation (2)

Re: Re: charin(), text_char() should return something else for empty input

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: charin(), text_char() should return something else for empty input
Date: 2001-05-28 19:25:09
Message-ID: 3.0.1.32.20010528122509.017b3100@mail.pacifier.com (view raw or flat)
Thread:
Lists: pgsql-hackers
At 02:37 PM 5/28/01 -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).
>
>Comments?

I personally wouldn't expect "char" to behave exactly as "char(1)",
because I understand it to be a one-byte variable which holds a single
(not zero or one) character.

Mapping '' to ' ' doesn't make a lot of sense to me.  It isn't what
I'd expect.

I think the behavior you describe in this note is better.



- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-05-28 19:59:43
Subject: Re: Re: charin(), text_char() should return something else for empty input
Previous:From: Tom LaneDate: 2001-05-28 19:15:57
Subject: Re: User functions and AIX

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group