On Tue, Jan 22, 2002 at 05:39:27PM +0100, H.Merijn Brand wrote: > On Tue 22 Jan 2002 17:26, Tim Bunce <[EMAIL PROTECTED]> wrote: > > On Tue, Jan 22, 2002 at 10:20:42AM +0100, H.Merijn Brand wrote: > > > On Tue 22 Jan 2002 00:16, "Jeff Urlwin" <[EMAIL PROTECTED]> wrote: > > > > 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). > > > > I agree. That's why whatever is added would always be optional and default off. > > > > > But this is *exacvtly* why I asked in the first place: > > > > > > insert into varchar column '' yields NULL when selected (in Oracle) > > > > > > Which is **NOT** what I put in! > > > > But that is a specific Oracle issue that's only related to ChopBlanks by > > virtue of how we may choose to work around it. > > > > > > 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. > > > > I'm leaning towards an DBD::Oracle private solution at the moment. > > No problem with that. > > > Tim. > > I rest my case. I think the group reached consensus: Expect to get out what > you put in => ergo don't chop varchar fields,
Well I'd say "expect to get out what you put in unless you've asked for some non-default behaviour". > but enable some method to inhibit NULL in oracle for empty varchar fields. And 'inhibit' will have to be some kind of masking hack, but hopefully a reasonably transparent one. Tim.
