Re: [GENERAL] 'a' == 'a ' - Mailing list pgsql-hackers

From Dann Corbit
Subject Re: [GENERAL] 'a' == 'a '
Date
Msg-id D425483C2C5C9F49B5B7A41F8944154757D21F@postal.corporate.connx.com
Whole thread Raw
Responses Re: [GENERAL] 'a' == 'a '
Re: [GENERAL] 'a' == 'a '
List pgsql-hackers
> -----Original Message-----
> From: Richard_D_Levine@raytheon.com
[mailto:Richard_D_Levine@raytheon.com]
> Sent: Thursday, October 20, 2005 2:12 PM
> To: Tom Lane
> Cc: Chris Travers; Dann Corbit; Greg Stark; josh@agliodbs.com; pgsql-
> general@postgresql.org; pgsql-hackers@postgresql.org; Marc G.
Fournier;
> Stephan Szabo; Terry Fielder; Tino Wildenhain
> Subject: Re: [GENERAL] [HACKERS] 'a' == 'a '
>
>
>
> Tom Lane <tgl@sss.pgh.pa.us> wrote on 10/20/2005 03:11:23 PM:
> <snip>
> > The hard part would be in figuring out how
> > the output routine could know how many spaces to add back.
>
> The length is in the metadata for the column, or am I being dense?

I guess that what Tom is saying is that it would be nice to store
everything as VARCHAR.  But with (for instance) BPCHAR, the returned
string is blank padded.  So if you store 'Danniel'
in BPCHAR(20), you will get back:'Danniel             '
But if you store 'Danniel'
In VARCHAR(20)
You will get back exactly what you put in.

I guess that additional ambiguity arises if you add additional spaces to
the end.  Many database systems solve this by trimming the characters
from the end of the string upon storage and the returned string will not
have any trailing blanks.  I am not arguing pro nor con this way of
doing things.


pgsql-hackers by date:

Previous
From: Andrew - Supernews
Date:
Subject: Re: Key violation. ERROR: type "lo" does not exist.
Next
From: Tom Lane
Date:
Subject: Re: 8.04 and RedHat/CentOS init script issue and sleep