Determining the type of an obkect in plperl

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.

David J.

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? You won’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!"