[postgis-devel] SVN trunk parser modifications stage 2

[Obe, Regina]

I was thinking about that myself how hard to get into postgresql.conf, but aren't only products baked into PostgreSQL allowed that luxury or can third-party products register their own config variables?


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Kevin Neufeld
Sent: Sat 10/18/2008 12:48 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] SVN trunk parser modifications stage 2
 
Hi Mark,

How many variables are you setting within the function call?  Typically 
in PostgreSQL, setting a variable at runtime for the duration of a 
session or transaction block, the SET command is used.

http://www.postgresql.org/docs/8.3/static/sql-set.html

ie.
SET SESSION client_min_messages TO DEBUG;
SET work_mem TO 131072;
SET LOCAL ENABLE_SEQSCAN TO OFF;


Have you considered using a similiar syntax for these PostGIS variables?
SET SESSION postgis_enable_parser_checks TO OFF;
or
SET postgis_incoming_parser_checks TO ON;
SET postgis_outgoing_parser_checks TO OFF;


I think having the variables is a great idea.  It'll allow users to keep 
the behaviour of the database as it is now, or customize their PostGIS 
install so it behaves more like SDE where only valid geometries are 
allowed in the database. 

I wonder if it'll work to store these variables in postgresql.conf?  
That way the behaviour can be set for a database cluster and all 
sessions as well.

Cheers,
Kevin

Mark Cave-Ayland wrote:
> Hi everyone,
>
> Now that the new parser API is in place, I'd like to discuss how we 
> can control its behaviour from within PostGIS/PostgreSQL. Normally the 
> parser is very strict in terms of validating input geometries, however 
> there have been a few documented cases where it is necessary to load 
> invalid data into the database in order for it to be cleaned up.
>
> I would like to propose that the parser behaviour can be toggled using 
> a set of in-built stored procedures similar to below:
>
>
> The documented API:
>
> SELECT postgis_disable_parser_checks()
>     - This will disable ALL checks performed by the parser for the
>     remaining duration of the connection. This will throw a very
>     large WARNING to let you know that what you are doing can will
>     potentially allow bad data into the database and that its
>     effects only last for the duration of the session.
>
> SELECT postgis_enable_parser_checks()
>     - This will re-enable ALL checks performed by the parser. Note
>     that all checks enabled will remain the default.
>
>
> The undocumented API:
>
> SELECT postgis_parser_checks(int, int)
>     - This will allow advanced developers the ability to specify the
>     parser checks as 2 bitmaps: 1 for incoming geometries, and 1 for
>     outgoing geometries (those generated by GEOS). It is designed
>     for use and testing by developers only.
>
>
> Note that I have deliberately named these functions so that they are 
> in the postgis_ namespace rather than the ST_ namespace, and so 
> developers should be well aware that what they are doing is definitely 
> outside of the OGC specification and that its behaviour is unique to 
> PostGIS.
>
> Once these changes have been committed, the final stage of the plan is 
> to move shp2pgsql/pgsql2shp over to use liblwgeom and the new stored 
> procedures (adding something like a --force option to trigger this 
> behaviour).
>
>
> Thoughts?
>
> Mark.
>
_______________________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20081018/a8587bd0/attachment.html>