[postgis-devel] SVN trunk parser modifications stage 2

[Obe, Regina]

Mark,
I suppose we can't just overload ST_GeomFromText with a 3rd parameter.
Or would that raise some eyebrows since we would have one version of the
function that is compliant and one that isn't.

or can we overload ST_GeomFromEWKT which is not compliant anyway and
deals with 3D which ST_GeomFromText currently doesn't anyway.
e.g.
Add 3 overloads
ST_GeomFromEWKT(ewkt text, srid integer) (always found it odd this
version was missing)
ST_GeomFromEWKT(ewkt text, boolean is_strict)
ST_GeomFromEWKT(ewkt text, srid integer, boolean is_strict)

With default being false for is_strict.
(or is_strict meant to be a level rather than a boolean?)
 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Monday, October 27, 2008 8:14 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] SVN trunk parser modifications stage 2

Kevin Neufeld wrote:
> Having a new variable in the custom_variable_classes list sounds like
a 
> good idea.
> 
> So, does this mean that we will be able to set the parser level for
the 
> duration of the transaction? Or can this only be set for the duration
of 
> the session?
> 
> SET LOCAL postgis.default_parser_check_level TO 0;
> -- or equivalently,
> SELECT set_config('postgis.default_parser_check_level', '0', true);
> 
> Cheers,
> Kevin

I now have some experimental code that uses just the plain GUC 
variables, and well... it's horrendously messy :(

The main issue is that due to PostgreSQL's delayed function loading, the

new GUC isn't available until the first PostGIS function is called which

causes some interesting synchronisation issues where either i) SHOW 
postgis.parser_check_level causes an ERROR if custom_variable_classes 
isn't set, and ii) changing the value using ALTER... SET cannot update 
the parser flags until the first time the parser is called. So using 
this, I was finding in testing that different combinations of commands 
in different orders would succeed or fail accordingly which is not good.

The problem with the stored procedures, of course, is that we can't 
easily reset to the default settings which makes interfacing with 
connection pooling particularly painful :(

On the basis of this, I'm now thinking that we need to take a different 
approach to get something that is going to work. I'm now thinking that 
the best way to approach this would be to tackle this from the 
input/output function perspective, perhaps having a separate function 
like ST_GeomFromTextWithStrict() or similar that will allow the correct 
strictness setting to be supplied. Then ST_GeomFromText() will remain 
OGC-compliant, while we give the user to chance to override this if 
required, much in the same way that ST_AsEWKT() works.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.