Skip site navigation (1) Skip section navigation (2)

Re: BUG #2240: length() with geometric types

From: James William Pye <pgsql(at)jwp(dot)name>
To: Andreas Erber <post(at)andreas-erber(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #2240: length() with geometric types
Date: 2006-02-07 01:22:51
Message-ID: 20060207012251.GA26495@lit.jwp.name (view raw or flat)
Thread:
Lists: pgsql-bugs
On Mon, Feb 06, 2006 at 02:41:39PM +0000, Andreas Erber wrote:
> 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?

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

In response to

Responses

pgsql-bugs by date

Next:From: Bruce MomjianDate: 2006-02-07 01:40:18
Subject: Re: [BUGS] BUG #2171: Differences compiling plpgsql in
Previous:From: Jim C. NasbyDate: 2006-02-06 23:54:05
Subject: SELECT max() won't use a NOT NULL index

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group