Re: [GENERAL] char(xx) problem

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>
Subject: Re: [GENERAL] char(xx) problem
Date: 1999-12-22 20:00:48
Message-ID: 199912221857.MAA25056@mail.xnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


> > 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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ed Loehr 1999-12-22 20:12:21 Re: [GENERAL] creating trigger
Previous Message Eldad Midan 1999-12-22 19:59:40 newbie needs help setting up pgsql on linux