[postgis-devel] Re: [postgis-users] Change default "canonicalform"of spatial objects

strk at refractions.net strk at refractions.net
Wed Mar 23 03:15:24 PST 2005


On Wed, Mar 23, 2005 at 11:08:21AM -0000, Mark Cave-Ayland wrote:
> Hi strk,
> 
> > -----Original Message-----
> > From: postgis-devel-bounces at postgis.refractions.net 
> > [mailto:postgis-devel-bounces at postgis.refractions.net] On 
> > Behalf Of strk at refractions.net
> > Sent: 23 March 2005 10:13
> > To: 'PostGIS Development Discussion'
> > Subject: Re: [postgis-devel] Re: [postgis-users] Change 
> > default "canonicalform"of spatial objects
> 
> (cut)
> 
> > Mark, your usage of view is probably enough for the average 
> > user, anyway (just for the sake of discussion), my 
> > postgis_set() function would set in-transaction variable. The 
> > canonical_ascii_output would by default be HEXWKB, so dumps 
> > (which starts in a new transaction) will always be HEXWKB and 
> > input would not be influenced. In-transaction settings might 
> > be also useful for other psql-based users. Think of something like:
> > 
> > 	postgis_set("precision", "15.15");
> > 	postgis_set("precision", "6");
> > 	postgis_set("bbox_cache_strategy", "auto");
> > 	postgis_set("bbox_cache_strategy", "when_simple");
> > 	...
> > 
> > ... Yes, would make things more complex, but do you see an 
> > use for it ?
> 
> Hmmm it could be something that we could consider... My immediate concern
> would be the penalty of looking up each of the variables during runtime, and
> how you could enforce transactional separation without the cost of storing
> the data in tuples (it may be quite easy to do it once per backend by
> storing the variables in memory but we'd have to make sure it didn't upset
> people using connection pooling).
> 
> IMHO it's something that would require quite a bit of testing, and so would
> be better to revisit this after 1.0.0 final release, especially as I think
> RC4 is definitely the closest yet... ;)

RC4 is out !
This is definitely to consider for 1.1.0, and I was wrong thinking
about transactional life of variables... I really meant session
lifetime (you're correct about pooling concerns).

--strk;

> 
> 
> Kind regards,
> 
> Mark.
> 
> ------------------------
> WebBased Ltd
> South West Technology Centre
> Tamar Science Park
> Plymouth
> PL6 8BT 
> 
> T: +44 (0)1752 791021
> F: +44 (0)1752 791023
> W: http://www.webbased.co.uk
> 
> 
> _______________________________________________
> 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