[postgis-devel] SVN trunk parser modifications stage 2

[David Fuhry]

One problem with the overloaded-function approach is that if a user 
pg_dumps their data (in COPY or INSERT mode), it won't be reloadable. 
(Unless they've pg_dumped to INSERT, and can use awk or something to 
wrap each geometry in the loose-parsing function call.)

The GUC and SELECT postgis_disable_parser_checks() approaches have the 
advantage that they can be set once, before the import, rather than 
having to touch every line of an import file.  (And they work with COPY.)

Things that easily break pg_dump ... | psql ... worry me.  I think a 
non-parser solution would also break (non-WAL) statement-based 
replication, when functions are evaluated on the master and tuples of 
the results are sent to slaves (where they're re-parsed).

-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.
>