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

From Julian Scarfe
Subject Re: [INTERFACES] Paths in DBD::Pg
Date
Msg-id 37412C77.B1002B62@callnetuk.com
Whole thread Raw
In response to Re: [INTERFACES] Paths in DBD::Pg  (selkovjr@mcs.anl.gov)
Responses Re: [INTERFACES] Paths in DBD::Pg
List pgsql-interfaces
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





pgsql-interfaces by date:

Previous
From: Jason Earl
Date:
Subject: Re: [INTERFACES] Problems with money fields.
Next
From: Hannu Krosing
Date:
Subject: Re: [INTERFACES] Problems with money fields.