Re: [INTERFACES] Paths in DBD::Pg

From: Julian Scarfe <jscarfe(at)callnetuk(dot)com>
To: selkovjr(at)mcs(dot)anl(dot)gov
Cc: pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: [INTERFACES] Paths in DBD::Pg
Date: 1999-05-18 09:01:43
Message-ID: 37412C77.B1002B62@callnetuk.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

selkovjr(at)mcs(dot)anl(dot)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

In response to

Browse pgsql-interfaces by date

  From Date Subject
Next Message Eildert Groeneveld 1999-05-18 09:05:45 Postmaster getting veeeery big
Previous Message Thomas Lockhart 1999-05-18 03:24:53 Re: [INTERFACES] Vacuum takes for ever