Re: [GENERAL] 'a' == 'a '

Поиск
Список
Период
Сортировка
От Dann Corbit
Тема Re: [GENERAL] 'a' == 'a '
Дата
Msg-id D425483C2C5C9F49B5B7A41F8944154757D21F@postal.corporate.connx.com
обсуждение исходный текст
Ответы Re: [GENERAL] 'a' == 'a '  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [GENERAL] 'a' == 'a '  (Richard_D_Levine@raytheon.com)
Список 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 по дате отправления:

Предыдущее
От: Andrew - Supernews
Дата:
Сообщение: Re: Key violation. ERROR: type "lo" does not exist.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 8.04 and RedHat/CentOS init script issue and sleep