Robert Haas wrote:
> > * inet datatypes don't have a commutative operator on which a unique
> > index can be built. There is no "overlaps" equivalent, which again is a
> > shame because that stops them being used with the new feature.
>
> This would be a nice thing to fix, and I was thinking about
Greg Stark wrote:
> On Mon, Mar 22, 2010 at 1:15 PM, Simon Riggs wrote:
> >
> > * Circles, Boxes and other geometric datatypes defined "overlaps" to
> > include touching shapes. So
> >
> > * inet datatypes don't have a commutative operator on which a unique
> > index can be built. There is no "ove
David Fetter wrote:
> On Mon, Mar 22, 2010 at 04:04:16PM -0300, Alvaro Herrera wrote:
> > David Fetter wrote:
> >
> > > diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
> > > index 9881ff4..9313112 100644
> > > --- a/doc/src/sgml/func.sgml
> > > +++ b/doc/src/sgml/func.sgml
> > > @@ -7
Simon Riggs wrote:
> I think you've missed my point.
> What I was talking about was that box '((0,0),(1,1))' && box
> '((1,1),(2,2))' returns true, even though they touch at only a
> single point, and share zero area.
FWIW, that's what I would take away from "one point in common"
-Kevin
-
On Mon, 2010-03-22 at 10:55 -0700, David Fetter wrote:
> On Mon, Mar 22, 2010 at 01:46:51PM -0400, Tom Lane wrote:
> > David Fetter writes:
> > > I'm seeing a lot of places where this might be documented. Any ideas
> > > as to which ones are appropriate?
> >
> > I would think "Geometric Function
On Mon, Mar 22, 2010 at 1:15 PM, Simon Riggs wrote:
>
> * Circles, Boxes and other geometric datatypes defined "overlaps" to
> include touching shapes. So
>
> * inet datatypes don't have a commutative operator on which a unique
> index can be built. There is no "overlaps" equivalent, which again i
On Mon, Mar 22, 2010 at 04:04:16PM -0300, Alvaro Herrera wrote:
> David Fetter wrote:
>
> > diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
> > index 9881ff4..9313112 100644
> > --- a/doc/src/sgml/func.sgml
> > +++ b/doc/src/sgml/func.sgml
> > @@ -7134,7 +7134,7 @@ CREATE TYPE rainbow
David Fetter wrote:
> diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
> index 9881ff4..9313112 100644
> --- a/doc/src/sgml/func.sgml
> +++ b/doc/src/sgml/func.sgml
> @@ -7134,7 +7134,7 @@ CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow',
> 'green', 'blue', 'purple
>
>
On Mon, Mar 22, 2010 at 01:46:51PM -0400, Tom Lane wrote:
> David Fetter writes:
> > I'm seeing a lot of places where this might be documented. Any ideas
> > as to which ones are appropriate?
>
> I would think "Geometric Functions and Operators" would be the most
> appropriate spot ...
Please f
David Fetter writes:
> I'm seeing a lot of places where this might be documented. Any ideas
> as to which ones are appropriate?
I would think "Geometric Functions and Operators" would be the most
appropriate spot ...
regards, tom lane
--
Sent via pgsql-hackers mailing
On Mon, Mar 22, 2010 at 04:47:37PM +, Simon Riggs wrote:
> On Mon, 2010-03-22 at 09:00 -0700, David Fetter wrote:
>
> > > Yes, for most people touching != overlap. So it just looks like a
> > > bug.
> >
> > I don't know which people you've surveyed, but at least in my math
> > classes, one po
On Mon, 2010-03-22 at 09:00 -0700, David Fetter wrote:
> > Yes, for most people touching != overlap. So it just looks like a
> > bug.
>
> I don't know which people you've surveyed, but at least in my math
> classes, one point in common was sufficient for an overlap. I'd be
> happy to write up so
Simon Riggs wrote:
Basically, what you feel is missing is documentation that if two
shapes share one or more points they are considered to overlap;
there is no requirement that they share an area?
Yes, for most people touching != overlap. So it just looks like a bug.
I guess I mu
Simon Riggs wrote:
> Yes, for most people touching != overlap. So it just looks like a
> bug.
A quick search of the web turned up a definition of overlap in
geometry as meaning that two polygons share at least one *internal*
point, which would be consistent with your interpretation; but there
On Mon, Mar 22, 2010 at 03:42:39PM +, Simon Riggs wrote:
> On Mon, 2010-03-22 at 10:32 -0500, Kevin Grittner wrote:
> > Simon Riggs wrote:
> > > On Mon, 2010-03-22 at 10:13 -0400, Tom Lane wrote:
> > >> Simon Riggs writes:
> >
> > >> > * Circles, Boxes and other geometric datatypes defined
On Mon, 2010-03-22 at 10:32 -0500, Kevin Grittner wrote:
> Simon Riggs wrote:
> > On Mon, 2010-03-22 at 10:13 -0400, Tom Lane wrote:
> >> Simon Riggs writes:
>
> >> > * Circles, Boxes and other geometric datatypes defined
> >> > "overlaps" to include touching shapes. So
> >> > SELECT circle '((
Simon Riggs wrote:
> On Mon, 2010-03-22 at 10:13 -0400, Tom Lane wrote:
>> Simon Riggs writes:
>> > * Circles, Boxes and other geometric datatypes defined
>> > "overlaps" to include touching shapes. So
>> > SELECT circle '((0,0), 1)' && circle '((2,0),1)';
>> > is true, which is fairly strange
On Mon, 2010-03-22 at 16:40 +0200, Peter Eisentraut wrote:
> On mån, 2010-03-22 at 13:15 +, Simon Riggs wrote:
> > * inet datatypes don't have a commutative operator on which a unique
> > index can be built. There is no "overlaps" equivalent, which again is a
> > shame because that stops them b
On mån, 2010-03-22 at 13:15 +, Simon Riggs wrote:
> * inet datatypes don't have a commutative operator on which a unique
> index can be built. There is no "overlaps" equivalent, which again is a
> shame because that stops them being used with the new feature.
http://pgfoundry.org/projects/ip4r
Simon Riggs writes:
> On Mon, 2010-03-22 at 10:13 -0400, Tom Lane wrote:
>>> Also, if the only common sense usage of exclusion constraints is GIST,
>>> why does the syntax default to "btree"?
>>
>> Since your "if" isn't a correct statement, the complaint doesn't follow.
> Docs say
> "The access
On Mon, 2010-03-22 at 10:13 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > * Exclusion indexes are created with the suffix "_exclusion". That's a
> > very long suffix and will overflow most defined reports/screens. It
> > would be much better to use just "_excl",
>
> No particular objection her
Simon Riggs writes:
> * Exclusion indexes are created with the suffix "_exclusion". That's a
> very long suffix and will overflow most defined reports/screens. It
> would be much better to use just "_excl",
No particular objection here.
> * Circles, Boxes and other geometric datatypes defined "o
On Mon, Mar 22, 2010 at 9:15 AM, Simon Riggs wrote:
> Exclusion constraints are good. There's a few annoyances around them,
> that are minor but feel should be addressed for 9.0.
>
> * Exclusion indexes are created with the suffix "_exclusion". That's a
> very long suffix and will overflow most de
Exclusion constraints are good. There's a few annoyances around them,
that are minor but feel should be addressed for 9.0.
* Exclusion indexes are created with the suffix "_exclusion". That's a
very long suffix and will overflow most defined reports/screens. It
would be much better to use just "_e
24 matches
Mail list logo
