[postgis-devel] Vive Doublebox -- need to have upgrade scripts fail gracefully at this point
Paul Ramsey
pramsey at opengeo.org
Wed Dec 7 13:01:43 PST 2011
No, we don't, we've never bothered, to my knowledge (nor should we,
we're in a development cycle!)
P.
On Wed, Dec 7, 2011 at 12:45 PM, Paragon Corporation <lr at pcorp.us> wrote:
> Given that it looks like we'll let this double thing live, we need to make
> sure that if people try to use the upgrade scripts it fails.
>
> Do we have revision logic in there anywhere? That checks the subversion one
> they are using
>
> thanks,
> Regina
>
>> -----Original Message-----
>> From: Paragon Corporation [mailto:lr at pcorp.us]
>> Sent: Wednesday, December 07, 2011 3:43 PM
>> To: 'PostGIS Development Discussion'
>> Subject: RE: [postgis-devel] Vive Doublebox
>>
>> Paul,
>>
>> Okay I will not stand in your way. In a sense I feel if I
>> played with the memory allocations things might be more even,
>> but I don't really have time for that exercise.
>> I will however try to compare the speeds of my production 1.5
>> with whatever new thing you commit.
>>
>> That said. You have my
>>
>> +0.33333333333333333333333333333333333333333333333333333333333
>> 3333333333
>> +3333333333333333333333333333333333333333333333333333333333333
>> 3333333333
>> +3333333333333333333333333333333333333333333333333333333333333
>> 3333333333
>> +33333333333333333333333333333333333333333333333
>>
>> Blessing
>>
>> Thanks,
>> Regina
>> > -----Original Message-----
>> > From: postgis-devel-bounces at postgis.refractions.net
>> > [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>> > dustymugs
>> > Sent: Wednesday, December 07, 2011 12:21 PM
>> > To: postgis-devel at postgis.refractions.net
>> > Subject: Re: [postgis-devel] Vive Doublebox
>> >
>> > On 12/07/2011 08:32 AM, Paul Ramsey wrote:
>> > > I was all ready to just move ahead and discard doublebox,
>> > and then I
>> > > realized that the next thing I'm going to move ahead on
>> (bbox type
>> > > with SRID support) will be pretty brutally impacted. One of
>> > the things
>> > > Sandro asked for in the bbox type was that it very quickly
>> > cast from
>> > > geometry. That implies reading the cached box. That implies
>> > that, if
>> > > we stay as we are, the result of
>> > >
>> > > 'LINESTRING(0 0, 1 1)'::geometry::bbox will be 'BOX(-0.00000001
>> > > -0.00000001, 1.00000001 1.000000001)'
>> > >
>> > > This is nothing new, it's what you get if you cast to
>> > box2d, but it's
>> > > more user visible cruft around having a float cache on a
>> value (the
>> > > bounds) that people expect to be exactly matching the
>> > coordinates. It
>> > > feels a shame to make a shiny brand new type and have it visibly
>> > > reflect one of the uglier design compromises of the 1.x series.
>> > >
>> > > I'm tempted to apply the doublebox to trunk, and just
>> > commit to trying
>> > > to make it faster over time.
>> > >
>> >
>> > Fine by me!
>> >
>> > -bborie
>> > _______________________________________________
>> > postgis-devel mailing list
>> > postgis-devel at postgis.refractions.net
>> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
>> >
>>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
More information about the postgis-devel
mailing list