Re: [INTERFACES] Paths in DBD::Pg - Mailing list pgsql-interfaces

From selkovjr@mcs.anl.gov
Subject Re: [INTERFACES] Paths in DBD::Pg
Date
Msg-id 199905191455.JAA19595@antares.mcs.anl.gov
Whole thread Raw
In response to Re: [INTERFACES] Paths in DBD::Pg  (Julian Scarfe <jscarfe@callnetuk.com>)
List pgsql-interfaces
> > You don't need to eval() individual points. If you eval() the whole
> > thing it will give you one single array:
> > 
> > @a = eval "((1,2),(3,4),(5,6))";
> > print "@a\n";
> 
> Sorry, the question wasn't very clear.  For subsequent processing I need
> the path as an array of two-element array references representing
> individual points. At the moment I have a choice of:
> 
> eval-ing the path into a flat array and then shifting them 2-by-2 into a
> suitable structure

It would be much quicker if you did popping instead of shifting, but
that gives you the wrong order. If you need it in the original order,
using array subscripts should be faster:

@a = eval "((1,2),(3,4),(5,6))";
foreach (my $i = 0; $i <= ($#a-1)/2; $i++ ) { push @ar, @a[$i, $i+1];
}

You may want to try this version as well -- it is more perlish, but I
don't know the cost of hash initialization. Should be comparable to
that of subscripts.

%a = eval "((1,2),(3,4),(5,6))";
while ( my ($x, $y) = each %a ) { push @ar, [$x,$y];
}

> tr-ing the ()s into []s to make [[1,2],[3,4],[5,6]] and them eval-ing
> that.

tr isn't quick, but it's a smart way of coding, if you want to
minimize the number of keystrokes ;)

> If there's nothing built into Pg for pulling out the structure in one
> go, I suppose it's time to get perlguts out... ;-)

I don't really think perlguts is where the answer is buried. I would
rather look into the FE/BE protocol to find out whether it can pass
around arrays instead of strings, then add a function to the path type
to output an array. They do pass arrays to the clients, the question
is how.

--Gene


pgsql-interfaces by date:

Previous
From: Herouth Maoz
Date:
Subject: Re: [INTERFACES] Postmaster getting veeeery big
Next
From: Eildert Groeneveld
Date:
Subject: Postmaster getting veeeery big: SUBSTR bug