Thread: Determining the type of an obkect in plperl

Probably a bit off topic, but I suspect someone on this list knows how to do
this.

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?


-- 
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
                        -- Benjamin Franklin

>
>how can I determine what the data type of the value element is?
>
perl has a ref function which can tell what type of object.

https://perldoc.perl.org/functions/ref.html
>


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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:
> 
> > Probably a bit off topic, but I suspect someone on this list knows how to
> > do
> > this.
> >
> > 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...
> 
> That would have to be faster than executing a type_of function on every
> single column.
> 
> Then measure performance and decide whether a generic routine is performant
> enough.  If not you might try creating custom function dynamically using
> the catalogs as input.

Since I am just looking for differences, this may work. Obviously comparing
numeric values as strings has issues.

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.
-- 
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
                        -- Benjamin Franklin

On Thu, Mar 05, 2020 at 12:27:12AM +0000, Ravi Krishna wrote:
> 
> > 
> > how can I determine what the data type of the value element is?
> > 
> perl has a ref function which can tell what type of object.
> 
> https://perldoc.perl.org/functions/ref.html
> > 
> 
> 

That was my goto answer, but see this in the docs:

If the operand is not a reference, then the empty string will be returned. 

So after I assign this to a variable this function does not help. I may
need to try using this against the actual _TD... hash

Thanks.

-- 
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
                        -- Benjamin Franklin

On Thu, Mar 05, 2020 at 12:27:12AM +0000, Ravi Krishna wrote:
> 
> > 
> > how can I determine what the data type of the value element is?
> > 
> perl has a ref function which can tell what type of object.
> 
> https://perldoc.perl.org/functions/ref.html
> > 
> 
> 
> --
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
Even checking gisnt teh _TD structure does not return a value:

foreach my $key (sort keys %{$_TD->{old}}) {
        my $ref1 =  ref $_TD->{old}->{$key};
        my $ref2 =  ref $_TD->{new}->{$key};
        elog(NOTICE, "ref1 = $ref1 ref2 = $ref2" );
        .
        .
        .


Results in the following output:

NOTICE:  ref1 =  ref2 = 



-- 
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
                        -- Benjamin Franklin

> On Mar 5, 2020, at 4:22 AM, stan <stanb@panix.com> wrote:
>
> On Thu, Mar 05, 2020 at 12:27:12AM +0000, Ravi Krishna wrote:
>>
>>>
>>> how can I determine what the data type of the value element is?
>>>
>> perl has a ref function which can tell what type of object.
>>
>> https://perldoc.perl.org/functions/ref.html
>>>
>>
>>
>> --
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
> Even checking gisnt teh _TD structure does not return a value:
>
> foreach my $key (sort keys %{$_TD->{old}}) {
>        my $ref1 =  ref $_TD->{old}->{$key};
>        my $ref2 =  ref $_TD->{new}->{$key};
>        elog(NOTICE, "ref1 = $ref1 ref2 = $ref2" );
>        .
>        .
>

I’m not a Perl guy but I don’t think you need to sort the keys. You don’t care what order the comparisons are done, do
you?
If it’s just “is different” your looking for why can’t you rely on Perl’s type coercing (toString()) on operands of ne?
Youwon’t have different types under the same key.  

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!"