Обсуждение: Paths in DBD::Pg

I'd like to deal with geometrical data types, paths in particular,
efficiently in Perl using Pg. But Pg, understadably I suppose, just
returns a path as a scalar string like ((1,2),(3,4),(5,6)). Whereas I
can 'eval' a point fairly efficiently, it's not very efficient to turn a
long string such as the above into an array of arrays.

Am I missing something in the Pg interface that would allow me to get
paths into sensible data structures efficiently?

Julian Scarfe

> I'd like to deal with geometrical data types, paths in particular,
> efficiently in Perl using Pg. But Pg, understadably I suppose, just
> returns a path as a scalar string like ((1,2),(3,4),(5,6)). Whereas I
> can 'eval' a point fairly efficiently, it's not very efficient to turn a
> long string such as the above into an array of arrays.

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


--Gene

selkovjr@mcs.anl.gov wrote:
> 
> > I'd like to deal with geometrical data types, paths in particular,
> > efficiently in Perl using Pg. But Pg, understadably I suppose, just
> > returns a path as a scalar string like ((1,2),(3,4),(5,6)). Whereas
> > I can 'eval' a point fairly efficiently, it's not very efficient to
> > turn a long string such as the above into an array of arrays.
> 
> 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

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

The tr-route is marginally quicker, but both feel inefficient and take a
significant part of my processing time for paths of significant length. 
If there's nothing built into Pg for pulling out the structure in one
go, I suppose it's time to get perlguts out... ;-)

Julian

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