pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedRe: [INTERFACES] Paths in DBD::Pg
4+ messages / 2 participants
[nested] [flat]
* Re: [INTERFACES] Paths in DBD::Pg
@ 1999-05-16 15:29 selkovjr@mcs.anl.gov
parent: Julian Scarfe <jscarfe@callnetuk.com>
0 siblings, 1 reply; 4+ messages in thread
From: selkovjr@mcs.anl.gov @ 1999-05-16 15:29 UTC (permalink / raw)
To: Julian Scarfe <jscarfe@callnetuk.com>; pgsql-interfaces
> 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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Paths in DBD::Pg
@ 1999-05-16 15:34 Julian Scarfe <jscarfe@callnetuk.com>
0 siblings, 1 reply; 4+ messages in thread
From: Julian Scarfe @ 1999-05-16 15:34 UTC (permalink / raw)
To: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [INTERFACES] Paths in DBD::Pg
@ 1999-05-18 09:01 Julian Scarfe <jscarfe@callnetuk.com>
parent: selkovjr@mcs.anl.gov
0 siblings, 1 reply; 4+ messages in thread
From: Julian Scarfe @ 1999-05-18 09:01 UTC (permalink / raw)
To: selkovjr@mcs.anl.gov; +Cc: 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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [INTERFACES] Paths in DBD::Pg
@ 1999-05-19 13:57 selkovjr@mcs.anl.gov
parent: Julian Scarfe <jscarfe@callnetuk.com>
0 siblings, 0 replies; 4+ messages in thread
From: selkovjr@mcs.anl.gov @ 1999-05-19 13:57 UTC (permalink / raw)
To: Julian Scarfe <jscarfe@callnetuk.com>; +Cc: 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
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~1999-05-19 13:57 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1999-05-16 15:34 Paths in DBD::Pg Julian Scarfe <jscarfe@callnetuk.com>
1999-05-16 15:29 ` selkovjr@mcs.anl.gov
1999-05-18 09:01 ` Julian Scarfe <jscarfe@callnetuk.com>
1999-05-19 13:57 ` selkovjr@mcs.anl.gov
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox