The following bug has been logged online:

Bug reference: 2240
Logged by: Andreas Erber
Email address: post (AT) andreas-erber (DOT) net
PostgreSQL version: 8.0.2
Operating system: Windows XP
Description: length() with geometric types
Details:

Hi,

I discovered some strange behaviour:
The length() function returns different results depending on the geometric
data type used as argument.

length(lseg) produces the correct result, i.e. length(lseg('(0,0),(2,0)')) =
2

length(path) always produces the double result (independently from the
length of the path), i.e.
length(path('(0,0),(2,0)')) = 4
length(path('(0,0),(2,0),(4,0),(6,0),(8,0)')) = 16

Is it supposed to be that way? If yes, why?

CU
ae

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

On Mon, Feb 06, 2006 at 02:41:39PM +0000, Andreas Erber wrote:
Yes.

You specified your path as a closed path. With its "loopback", it's twice as
long.

To specify it as an open path, do path('[(0,0),(2,0)]').

SELECT length(path('[(1,0),(0,0)]')) = '1';
SELECT length(path('(1,0),(0,0)')) = '2';
--
Regards, James William Pye

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

This is a multi-part message in MIME format.
--------------010105010105030006090006
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

sorry to bug you with that. I figured that out, too, in the meantime. I
wonder why the default behaviour of the path-constructor to end up in a
closed path. I would intentionally expect an open path - since I
understand a path as a connection of points that go from a start to a
destination and not necessarily back. If I would like to have a closed
path I would probably use the polygon datatype.

What was the intenion behind some of the geometric datatypes anyway. I
would have liked to work with them (esp. path) but they turned out not
to be very useful. (I cannot append or prepend a point to a path, I
cannot index-access it, I didn't even find a way to cast it to a string).

Is there any further development planned or will you keep this status? I
would prefer to see these datatypes handier in the future so they
probably get more useful.

Thx
CU
ae

James William Pye schrieb:
- --
- ------------------------------------------------------
Information is a weapon of mass destruction
[Faithless]
- ------------------------------------------------------
Andreas Erber
Berlin
Germany
- ----------------------------------------------------
e-mail post (AT) andreas-erber (DOT) net
home http://www.andreas-erber.net
- ----------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD6KhuBzgniz6LxFMRArrzAJ49GKPSOqB+S3ifW/RRzCEPjvMFOQCeMJjn
AJX3rHfm+YEzEcfJv5epuf4=
=6+08
-----END PGP SIGNATURE-----

--------------010105010105030006090006
Content-Type: text/x-vcard; charset=utf-8;
name="post.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="post.vcf"

YmVnaW46dmNhcmQNCmZuOkFuZHJlYXMgRXJiZXINCm46RXJiZX I7QW5kcmVh
cw0KYWRyOjs7TWF4aW1pbGlhbnN0ci4gNDVBO0JlcmxpbjtCZX JsaW47MTMx
ODc7R2VybWFueQ0KZW1haWw7aW50ZXJuZXQ6cG9zdEBhbmRyZW FzLWVyYmVy
Lm5ldA0KdGl0bGU6Y2FuZC4gcmVyLiBuYXQuDQp0ZWw7Y2VsbD orKzQ5MTcy
MzA3MTY2Nw0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpodH RwOi8vd3d3
LmFuZHJlYXMtZXJiZXIubmV0DQp2ZXJzaW9uOjIuMQ0KZW5kOn ZjYXJkDQoN
Cg==

--------------010105010105030006090006
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

--------------010105010105030006090006--