Re: Geometric data type for an arc.

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: John(dot)Kitz(at)xs4all(dot)nl, pgsql-novice(at)postgresql(dot)org
Subject: Re: Geometric data type for an arc.
Date: 2012-05-10 17:07:10
Message-ID: CAHyXU0xBaU9sU8BqVSh3zJqq5U-A=2gjhn_6+5t+TK6p8d9pKg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

On Thu, May 10, 2012 at 11:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> On Thu, May 10, 2012 at 10:10 AM, John W. Kitz <John(dot)Kitz(at)xs4all(dot)nl> wrote:
>>> Does anybody know how to submit a feature request for consideration to the
>>> developers of PostgreSQL?
>
>> The support for geometric types as it stands is fairly weak -- there
>> might be some reluctance to extend them (which means more operators,
>> casts, etc) without a more general look at their issues (for example,
>> why can't you extract points out of a box type)?
>
> The first question that would be asked is whether PostGIS doesn't do
> what you want.  There's not that much enthusiasm for improving the core
> geometric types because PostGIS has covered the territory.

It doesn't -- it's pretty much a polygon based system -- and PostGIS
is a huge dependency if all you want to do is store an arc for later
extraction. IMO, the threshold for advising PostGIS should be
manipulation and precise searching, not necessarily working with
geometric objects.

I've often wondered if the built in geometric types could be
approximated with composites and arrays -- trading an efficiency loss
for flexibility and standardization.

merlin

In response to

Browse pgsql-novice by date

  From Date Subject
Next Message Pat Pascal 2012-05-10 23:33:34 PL/TCLu Function Waiting for External Java/JDBC Application
Previous Message Alan Hodgson 2012-05-10 17:07:09 Re: I am NOT a programmer!