Bruce Momjian wrote:
What additional documentation is needed?
Some specific discussion of the relationship to the standard would be
helpful, perhaps.
I guess, but explaining it seems pretty complex in itself, and I am
unsure what value it adds.
It will give us something to
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I understand now. It is tempting to think that the difference
> > between char() and varchar() is that internally they use a different
> > collating sequences, but that isn't the case. If it were, space would
> > be ignored during comparisons any p
Bruce Momjian writes:
> OK, I understand now. It is tempting to think that the difference
> between char() and varchar() is that internally they use a different
> collating sequences, but that isn't the case. If it were, space would
> be ignored during comparisons any place in the string, when i
Dann Corbit wrote:
> > But isn't collating sequence related to ordering? How does this
> relate
> > to padding?
>
> Right. Collating sequence is how ordering is defined. But when you
> compare two character types, they are supposed to pad according to the
> collating sequence. So whether you b
Dann Corbit wrote:
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> > Sent: Monday, October 24, 2005 5:57 PM
> > To: Dann Corbit
> > Cc: Tom Lane; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> > pgsql-hackers@postgresql.org
> >
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 24, 2005 5:57 PM
> To: Dann Corbit
> Cc: Tom Lane; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> pgsql-hackers@postgresql.org
> Subject: Re: [GENERAL] [HACKERS] 'a'
mailto:[EMAIL PROTECTED]
> > Sent: Monday, October 24, 2005 11:01 AM
> > To: Tom Lane
> > Cc: Dann Corbit; [EMAIL PROTECTED];
> [EMAIL PROTECTED];
> > pgsql-hackers@postgresql.org
> > Subject: Re: [GENERAL] [H
esql.org
> Subject: Re: [GENERAL] [HACKERS] 'a' == 'a '
>
>
> Is there any TODO here?
>
>
--
> -
>
> Tom Lane wrote:
> > "Dann Corbit" <[EMAIL PROTECTED]> w
Is there any TODO here?
---
Tom Lane wrote:
> "Dann Corbit" <[EMAIL PROTECTED]> writes:
> > I guess that additional ambiguity arises if you add additional spaces to
> > the end. Many database systems solve this by trimming
I wonder how widespread the MicroSoft behavior is Sybase ASE,
for example, gives this result set:
30 5 30 5
That seems more appropriate to me.
-Kevin
> "Dann Corbit" <[EMAIL PROTECTED]> writes:
> > I guess that additional ambiguity arises if you add addit
Dann Corbit; Greg Stark; josh@agliodbs.com; pgsql-
> > [EMAIL PROTECTED]; pgsql-hackers@postgresql.org; Marc G.
> Fournier;
> > Stephan Szabo; Terry Fielder; Tino Wildenhain
> > Subject: Re: [GENERAL] [HACKERS] 'a' == 'a '
> >
> >
> >
> > T
[Removed all the non-list addresses]
Dann Corbit wrote:
Let me make something clear:
When we are talking about padding here it is only in the context of a
comparison operator and NOT having anything to do with storage.
Given two strings of different in a comparison, most database systems
(by d
I will happily reiterate that I am the troll who started this mess by
whining about how *Oracle* handles this. Tom's explanation that CHAR is
has a PAD collation and VARCHAR has a NO PAD collation have restored my
faith that there is goodness in the world. My whining was out of
ignorance. I woul
At 05:33 PM 10/19/2005 -0700, Dann Corbit wrote:
If there is a significant performance benefit to not expanding text
columns in comparison operations, then it seems it should be OK.
I probably read the standard wrong, but it seems to me that varchar, char,
and bpchar columns should all behave
Tom Lane <[EMAIL PROTECTED]> wrote on 10/20/2005 03:11:23 PM:
> 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?
>
> regards, tom lane
--
Dann Corbit wrote:
>> -Original Message-
>> From: Tom Lane [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, October 20, 2005 2:54 PM
>> To: Dann Corbit
>> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; pgsql-
>> [EMAIL PROTECTED] Subject: Re: [GENERAL] [HACK
Dann Corbit wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 20, 2005 2:54 PM
To: Dann Corbit
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; pgsql-
[EMAIL PROTECTED]
Subject: Re: [GENERAL] [HACKERS] 'a' == 'a '
"Dann
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 20, 2005 2:54 PM
> To: Dann Corbit
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; pgsql-
> [EMAIL PROTECTED]
> Subject: Re: [GENERAL] [HACKERS] 'a' == 'a '
>
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> 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.
Can yo
[EMAIL PROTECTED] writes:
> Tom Lane <[EMAIL PROTECTED]> wrote on 10/20/2005 03:11:23 PM:
>> 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?
The output routine hasn't got
r;
> Stephan Szabo; Terry Fielder; Tino Wildenhain
> Subject: Re: [GENERAL] [HACKERS] 'a' == 'a '
>
>
>
> Tom Lane <[EMAIL PROTECTED]> wrote on 10/20/2005 03:11:23 PM:
>
> > The hard part would be in figuring out how
> > the output routi
Chris Travers <[EMAIL PROTECTED]> writes:
> IIrc, varchar and bpchar are stored in a similar way, but are presented
> differently when retrieved. I.e. storage is separate from presentation
> in this case. I.e. the padding in bpchar occurs when it is presented
> and stripped when it is stored.
ctober 20, 2005 12:53 PM
> To: Dann Corbit
> Cc: ; pgsql-general General
> Subject: Re: [GENERAL] [HACKERS] 'a' == 'a '
>
> [Removed all the non-list addresses]
>
> Dann Corbit wrote:
>
> > Let me make something clear:
> > When we are talking
> Marc G. Fournier; [EMAIL PROTECTED]; pgsql-
> [EMAIL PROTECTED]
> Subject: Re: [GENERAL] [HACKERS] 'a' == 'a '
>
> Dann Corbit wrote:
>
> >Let me make something clear:
> >When we are talking about padding here it is only in the context of
Dann Corbit wrote:
Let me make something clear:
When we are talking about padding here it is only in the context of a
comparison operator and NOT having anything to do with storage.
IIrc, varchar and bpchar are stored in a similar way, but are presented
differently when retrieved. I.e. stor
Szabo; Terry Fielder; Tino Wildenhain; Marc G.
Fournier;
> [EMAIL PROTECTED]; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] [HACKERS] 'a' == 'a '
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Chris Travers <[EMAIL PROTECTED]> writes:
&
On 10/20/2005 2:17 AM, Greg Stark wrote:
(I can't believe anyone really wants varchar to be space padded. Space padding
always seemed like a legacy feature for databases with fixed record length
data types. Why would anyone want a string data type that can't represent all
strings?)
They must h
Tom Lane <[EMAIL PROTECTED]> writes:
> Chris Travers <[EMAIL PROTECTED]> writes:
> > If I understand the spec correctly, it seems to indicate that this is
> > specific to the locale/character set.
>
> The spec associates padding behavior with collations, which per spec are
> separate from the da
Chris Travers <[EMAIL PROTECTED]> writes:
> If I understand the spec correctly, it seems to indicate that this is
> specific to the locale/character set.
The spec associates padding behavior with collations, which per spec are
separate from the datatypes --- that is, you should be able to able to
Josh Berkus wrote:
Dann,
I think that whatever is done ought to be whatever the standard says.
If I misinterpret the standard and PostgreSQL is doing it right, then
that is fine. It is just that PostgreSQL is very counter-intuitive
compared to other database systems that I have used in thi
30 matches
Mail list logo
