On 2020-03-05 05:59:10 -0500, stan wrote:
> On Wed, Mar 04, 2020 at 05:09:19PM -0700, David G. Johnston wrote:
> > On Wed, Mar 4, 2020 at 4:21 PM stan <stanb@panix.com> wrote:
> > > I am in the process of writing a plperl function. In this function
> > > I need to compare the data in the NEW versus OLD structures. I am
> > > writing this as a generic subroutine, so I am looping through and
> > > comparing the 2 to see what is different. Problem is, that I need
> > > to know whether to us n != or a ne comparison.
> > >
> > > how can I determine what the data type of the value element is?
> > >
> >
> > Not up to speed on Perl but you basically want everything to be done using
> > string equality - can't you just use "ne" everywhere and not worry about
> > comparing numbers using string comparison logic? Might want to disabled
> > warnings...
[...]
>
> Since I am just looking for differences, this may work.
It should work. In fact it is probably the most robust method. Perl
scalars don't have a type like "int" or "string". They can be both (or
neither) at the same time. Also, a numeric comparison may not be the
right thing even for values which look like numbers:
Consider:
#!/usr/bin/perl
use v5.12;
use warnings;
use Scalar::Util qw(looks_like_number);
my $x = "123456789012345678901";
my $y = "123456789012345678902";
say "eq(1): ", $x eq $y;
if (looks_like_number($x) && looks_like_number($y)) {
say "==(2): ", $x == $y;
} else {
say "eq(2): ", $x eq $y;
}
say "eq(3): ", $x eq $y;
This will print
eq(1):
==(2): 1
eq(3):
on my system: The string comparisons correctly determine $x and $y to be
not equal, but the numeric comparison says they are equal (the two
numbers are too large to fit into a 64 bit unsigned int, so perl will
use a 64 bit float for the comparison which will cause both to be
rounded to 123456789012345683968).
(I included the second string comparison to check that the numeric
comparison didn' affect the values, which I wasn't sure of).
> Presently I am getting some warnings, so I think I need to deal with the
> types. I already dealt with the columns that return NULL, these are
> undefined in the Perl hash, so I have to test for their existence before
> attempting the compare.
What do you mean by "undefined in the hash"?
* The keys exist but the values are undef
* The keys don't exist
Those are not the same thing, and you use different functions to test
for them (defined() and exists() respectively).
(I think it should be the former, but I'm too lazy to test it myself)
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"