[postgis-devel] SVN trunk parser modifications stage 2

David Fuhry dfuhry at acm.org
Mon Oct 27 08:46:17 PDT 2008


One problem with all of the function-overloading ideas, is that if you 
backup your geometries using pg_dump (COPY or INSERT mode), you won't 
necessarily be able to reimport them.  (Without using INSERT mode and 
writing an ugly script to wrap geometry fields in the loose parsing 
function.)

The GUC or SELECT postgis_disable_parser_checks() approaches would only 
require making one call before import, rather than touching every line 
in the import file.

-Dave

Obe, Regina wrote:
> 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.
> 



More information about the postgis-devel mailing list