Re: Determining the type of an obkect in plperl - Mailing list pgsql-general

From Peter J. Holzer
Subject Re: Determining the type of an obkect in plperl
Date
Msg-id 20200308195044.GC22585@hjp.at
Whole thread Raw
In response to Re: Determining the type of an obkect in plperl  (stan <stanb@panix.com>)
List pgsql-general
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!"

Attachment

pgsql-general by date:

Previous
From: "Peter J. Holzer"
Date:
Subject: Re: Advice request : simultaneous function/data updates on manydatabases
Next
From: "Peter J. Holzer"
Date:
Subject: Re: Real application clustering in postgres.