Re: [HACKERS] 'a' == 'a '

> -----Original Message-----
> From: Chris Travers [mailto:chris(at)travelamericas(dot)com]
> Sent: Thursday, October 20, 2005 11:53 AM
> To: Dann Corbit
> Cc: Greg Stark; Tom Lane; Chris Travers; josh(at)agliodbs(dot)com; pgsql-
> hackers(at)postgresql(dot)org; Stephan Szabo; Terry Fielder; Tino Wildenhain;
> Marc G. Fournier; Richard_D_Levine(at)raytheon(dot)com; pgsql-
> general(at)postgresql(dot)org
> 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 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. 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.
>
> Again, I am happy "solving" this simply by documenting it since any
> questions of interpretation and implimentation of the standard would
be
> answered. So far what I (and I am sure others) have not heard is a
> strong case for changing the behavior, given that it is in line with a
> reasonable interpretation of the standards.

I believe that this is a reasonable response. In order to comply with
the standard, bpchar and varchar would have to be stored with different
default collating sequences (which is fine with me). If (indeed) that
is the case, the only action needed would be to document the collating
sequences used.

> >Given two strings of different in a comparison, most database systems
> >(by default) will blank pad the shorter string so that they are the
same
> >length before performing the comparison.
> >
> >
> Understood, but what gain do you have in a case like this that might
> justify the effort that would go into making it, say, an initdb
option?
> How often does this behavior cause problems?

I do not even know if it is a good idea. I was just pointing out that
the behavior of PostgreSQL is different from all the big database
vendors in this area and according to my reading of the standard, the
behavior was not compliant.

As to how often it causes a problem, I can't say. It has caused me
puzzlement on a few occasions, but no end of the world disasters.