In case you hadn't noticed, I'm trying to get to where you are telling me I
should go... Right now they are both being right trimmed. I would like to do
away with all default trimming but I do have a strong feeling that over 90%
actually want whitespace off the ends of their strings trimmed. Where were
you when we had this brawl some time ago?

It isn't uncommon for the majority rule to take precedence over mathematical
correctness. In the case of IBO, if you are the unusual case that needs
whitespace left alone it is a simple setting to do so. That was the decision
I made back when I made it this way.

Now that IBO allows centralized rules for domains I think it is easy to make
either make their settings. Assuming people use domains, it is trivial to
make a list of your domains and flag them with the behaviors you want for
them. Trimming is included in that. Because of this ease, I would like to
move more towards mathematical correctness, written differently "don't touch
my data!".

Any additional comments here... Even if someone has said what you think, let
me know. I am feeling for a strong consensus here.

Thanks,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "David Trudgett" <dkt@...>
To: <IBObjects@yahoogroups.com>
Sent: Thursday, March 22, 2001 3:50 PM
Subject: Re: [IBO] ib_query ignores my data!


> At 2001-03-22 13:28 -0700, "Jason Wharton" <jwharton@...> wrote:
>
> >I am more in favor of a column type based rule than a column length
based
> >rule on the default trimming behavior. I also think that CHAR columns are
> >expected to be fixed length and so trimming is mostly likely undesirable
> >there. VARCHAR on the other hand is meant to be variable length so
trimming
> >is most likely welcomed there.
>
> I think that is entirely untrue. As a matter of fact, there is no reason
to
> suppose that a space character is any different from any other type of
> character, whether it's in a varchar or not. Don't tread on users' data by
> default! Would you gratuitously trim off zeroes because you happen to
think
> they're meaningless? (But we'll only do it in varchars, so that's ok! ;-))
> Getting my point? :-) Trimming (by default) is a bad, bad, bad idea,
> because it makes invalid assumptions about the nature of the user's data.
> Databases don't impose their own view of data onto users: they just store
> it and serve it up (more or less).
>
> How many specific examples of where spaces are important need to be
pointed
> out?
>
> Communications applications that demand space padding (the designer may
> choose to store raw comms data in the database).
>
> Encryption applications, which may generate spaces in the output (even at
> the end!)
>
> Arrays of flags, where a space signifies 'default' (just don't default the
> last one!)
>
> You may not do these things yourself, but people out there do, and these
> people sure won't be happy about forced (or even default) trimming of
spaces.
>
>
>
>
> >How does this sound to everyone?
>
> Not good, in case you haven't guessed by now! :-)
>
>
>
> >Just so you know how this change will affect people... I am currently
right
> >trimming both CHAR and VARCHAR column types. If you have a name column as
> >CHAR after this change you are going to get padding spaces at the end of
all
> >your columns. Perhaps this should only be done by changing the minor
version
> >number to IBO v3.7 and also do it in IBO v4. Or, should I just do this in
> >IBO v4 and leave 3.x totally alone here?
>
> Leave it for V4, in my opinion (unless that's a long, long, way away).
But,
> please, do the same to both CHAR and VARCHAR. There is absolutely no
reason
> to separate the two in this regard.
>
>
> >Thanks for all the input on this important issue.
>
> Just remember the cardinal rule: don't mess with people's data! You can't
> _assume_ you can change data just because you psychologically think of a
> space character as different from any other character. It definitely
isn't!
>
>
> David Trudgett
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>