Re: [GENERAL] char(xx) problem

Yes, u understood me right,
I plane to install new version in january, and if the problem still exist,
I;ll report it again
--------------------------------------------------------------
The reboots are for hardware upgrades!
"http://www.nmmm.nu; <nmmm(at)nmmm(dot)nu>

----- Original Message -----
From: Gene Selkov <selkovjr(at)mcs(dot)anl(dot)gov>
To: Herouth Maoz <herouth(at)oumail(dot)openu(dot)ac(dot)il>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Sent: сряда, Декември 22, 1999 10:00
Subject: Re: [GENERAL] char(xx) problem

>
> > > I'm just wondering: are there any alternatives to blank padding? Why
> > > is it done in the first place?
> >
> > That's how fixed-length char type works, since the early days of SQL.
You
> > come to expect it, which means that if you use legacy code that has a
> > fixed-width char type, or you decided to use it for its time-saving
> > possibilities, it should behave according to some way which has been
> > established long ago.
>
> I thik I understand why a fixed-size type should be aligned to the
> multiples of its size in storage -- that's what accounts for some
> speed improvement. I am still not getting the point when it comes to
> padding. Because it looks like it draws on speed -- both when you do
> the padding and when you trim the results. The question is
> whether a null-terminated string would do as well.
>
> My suspicion is that somebody simply didn't like to see the garbage in the
> database files, and then it stuck.
>
> > What I don't get is why, given two bpchar argument, Postgres doesn't
just
> > pad the shorter one to the length of the other and then compares,
selects
> > and whatnot.
>
> As the original post by Nikolay Mijaylov indicated, there is (was?) a
> mechanism for correct comparison between various char(*) and text
> types, but whether it works or not depends on the weather outside. I
> can witness its existence in the past, as I still have some code that
> relies on cross-type comparisons which do not seem to work
> anymore. Unfortunately, I did not check since a few versions back, but
> if I understood Nikolay Mijaylov right, he claims to have two
> installations of the same version that behave differently.
>
> Now these code snippets clearly shows how it was intended to work:
>
>
> /*
****************************************************************************
> * Comparison Functions used for bpchar
> *
****
************************************************************************/
>
> static int
> bcTruelen(char *arg)
> {
> char *s = VARDATA(arg);
> int i;
> int len;
>
> len = VARSIZE(arg) - VARHDRSZ;
> for (i = len - 1; i >= 0; i--)
> {
> if (s[i] != ' ')
> break;
> }
> return i + 1;
> }
>
>
> . . . .
>
>
> bool
> bpchareq(char *arg1, char *arg2)
> {
> int len1,
> len2;
>
> if (arg1 == NULL || arg2 == NULL)
> return (bool) 0;
> len1 = bcTruelen(arg1);
> len2 = bcTruelen(arg2);
>
> if (len1 != len2)
> return 0;
>
> return strncmp(VARDATA(arg1), VARDATA(arg2), len1) == 0;
> }
>
> What's up with bcTruelen() then? Where does the noise come from?
>
>
> --Gene
>
> ************