Up Prev Next
From: Martin Rieder <Martin dot Rieder at morganstanley dot com>
Subject: Re: A patch proposal to the NULL-value problem on blk_rowxfer
Date: Jun 19 2002 7:29PM
I was frustrated the first time I encountered this issue with what I thought
was undef integer values. I am OK with the API working as it does and the
little bit of extra processing to explicitly set NULL value to undef, but I
would be in favor adding some words of wisdom to the documentation (maybe add
to the sample code) in the appropriate places to help users understand/avoid
this issue, especially when dealing with numeric data.
Michael Peppler wrote:
> On Wed, 2002-06-19 at 08:05, Masatsuyo Takahashi wrote:
> > I'd like to propose a patch to fix the NULL-value problem on blk_rowxfer
> > recently posted by Hiroshi Yamada and answered by Martin Rieder.
> > I'll clarify the situation first, discuss what to fix, and then show the
> > patch.
> > THE CAUSE OF TROUBLE
> > The problem comes from the three silmilar but different states
> > of an array element, namely,
> > (NA) where nothing is assigned yet
> > (UD) where 'undef' has been assigned
> > (NS) where null string '' ha been assigned.
> > Thus, I think, in a Perl-like way, it is fair for CTlib.xs to conform to
> > Perl.
> > That is, all the three states in Perl should be converted within CTlib.xs
> > into NULLs in Sybase.
> > Perl(XS) Sybase
> > -----------------
> > NA => NULL
> > UD => NULL
> > NS => NULL
> I agree on the first two. For the last one I have a bit of a problem -
> and that is related to the never ending argument about empty strings in
> varchar() columns which end up having a single space (i.e. insert "" to
> a varchar column will produce " " in the database).
> Scott's comment that an empty string and a NULL value are different is,
> in my opinion, relevant.
> So the question is - should blk_rowxfer() be modified to coerce the
> empty string to NULL, or should it be the caller's responsibility to
> make sure that any values where NULL is expected actually have undef,
> and not the empty string?
> Personally I tend towards the latter (and maybe Sybase::BLK needs to be
> modified to properly address this issue?).
> Anyone else care to comment?
> (to make things really confusing the behavior could be made
> > Especially, without the "!svp" condition, it may cause memory faults
> > for 'NA(not assigned)' cases.
> Yes - absolutely - thanks for catching that!
> Michael Peppler / email@example.com / http://www.mbay.net/~mpeppler
> firstname.lastname@example.org / ZetaTools, Inc / http://www.zetatools.com
> ZetaTools: Call perl functions as Sybase stored procedures!
> Name: signature.asc
> signature.asc Type: application/pgp-signature
> Description: This is a digitally signed message part