Tim,

I'm against it.  Reasoning: char (and nchar) columns are, at least in my
experience, PADDED by the DB.  Varchar columns, typically, are not.  Thus:
        insert into char colum 'A' yeilds 'A    ' when selected (of course,
depending upon the size of the column) whereas
        insert into varchar column 'A' yields 'A' when selected.

It seems to me that trimming char columns is important so that you get out
what you put in (most of the time).  It seems that trimming varchar columns
means you don't get out what you put in.  I do believe we should attempt to
get out what you put in, not make decisions for the programmer(s).  It's
simple enough to pick the columns you want trimmed and s/s+$//;  In my
experience, I almost always trim CHAR columns and almost never trim varchar
columns, based upon what I put into them and what I expect out...

Of course, that's my opinion and subject to those with broader experience.

Jeff

> -----Original Message-----
> From: Tim Bunce [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 21, 2002 6:16 AM
> To: Jonathan Leffler
> Cc: Tim Bunce; H.Merijn Brand; DBD Informix Maintenance Team; DBI
> developers
> Subject: Re: ChopBlanks
>
>
> On Sun, Jan 20, 2002 at 11:01:17PM -0800, Jonathan Leffler wrote:
> > Tim Bunce wrote:
> >
> > >I'd appreciate any input from driver authors who either:
> > >
> > >a) set ChopBlanks on by default (which they probably shouldn't)
> >
> > Not guilty (referring to DBD::Informix, of course).  Is ChopBlanks
> > settable in the DBI->connect?
> > If not, please can we make it so (and if it is, thanks, and when did
> > that happen - and I know it was probably 5 years ago, but ...)
>
> Probably 5 years ago :)
>
> > >or
> > >b) don't want ChopBlanks extended to VARCHAR fields
> >
> > I take the view that trailing blanks are nominally significant in a
> > VARCHAR field.  If you want to provide ChopBlanks functionality for
> > VARCHAR too, use a separate attribute ChopVarcharBlanks or something.
> >
> > I fully accept that distinguishing an empty string from a NULL is hard
> > work - I don't want to explain what Informix does, but it does
> manage to
> > do it for VARCHARs at the storage level.  It's just a real pain at the
> > client side (meaning for DBD::Informix).
> >
> > >(Let's defer the issue of which _specific_ string types ChopBlanks
> > >should apply to for now and just consider CHAR and VARCHAR's at
> > >this point.)
> >
> > OK.  NCHAR and CHAR should be chopped.  VARCHAR and NVARCHAR should not.
> > Anything else is not fully standard.  Speaking personally, I
> don't think
> > text blobs should be chopped for the same reasons that varchar should
> > not - they are nominally significant.
>
> Ok, thanks.
>
> Tim.
>

Reply via email to