<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>RE: [postgis-devel] SVN trunk parser modifications stage 2</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>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?<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Kevin Neufeld<BR>
Sent: Sat 10/18/2008 12:48 PM<BR>
To: PostGIS Development Discussion<BR>
Subject: Re: [postgis-devel] SVN trunk parser modifications stage 2<BR>
<BR>
Hi Mark,<BR>
<BR>
How many variables are you setting within the function call? Typically<BR>
in PostgreSQL, setting a variable at runtime for the duration of a<BR>
session or transaction block, the SET command is used.<BR>
<BR>
<A HREF="http://www.postgresql.org/docs/8.3/static/sql-set.html">http://www.postgresql.org/docs/8.3/static/sql-set.html</A><BR>
<BR>
ie.<BR>
SET SESSION client_min_messages TO DEBUG;<BR>
SET work_mem TO 131072;<BR>
SET LOCAL ENABLE_SEQSCAN TO OFF;<BR>
<BR>
<BR>
Have you considered using a similiar syntax for these PostGIS variables?<BR>
SET SESSION postgis_enable_parser_checks TO OFF;<BR>
or<BR>
SET postgis_incoming_parser_checks TO ON;<BR>
SET postgis_outgoing_parser_checks TO OFF;<BR>
<BR>
<BR>
I think having the variables is a great idea. It'll allow users to keep<BR>
the behaviour of the database as it is now, or customize their PostGIS<BR>
install so it behaves more like SDE where only valid geometries are<BR>
allowed in the database.<BR>
<BR>
I wonder if it'll work to store these variables in postgresql.conf? <BR>
That way the behaviour can be set for a database cluster and all<BR>
sessions as well.<BR>
<BR>
Cheers,<BR>
Kevin<BR>
<BR>
Mark Cave-Ayland wrote:<BR>
> Hi everyone,<BR>
><BR>
> Now that the new parser API is in place, I'd like to discuss how we<BR>
> can control its behaviour from within PostGIS/PostgreSQL. Normally the<BR>
> parser is very strict in terms of validating input geometries, however<BR>
> there have been a few documented cases where it is necessary to load<BR>
> invalid data into the database in order for it to be cleaned up.<BR>
><BR>
> I would like to propose that the parser behaviour can be toggled using<BR>
> a set of in-built stored procedures similar to below:<BR>
><BR>
><BR>
> The documented API:<BR>
><BR>
> SELECT postgis_disable_parser_checks()<BR>
> - This will disable ALL checks performed by the parser for the<BR>
> remaining duration of the connection. This will throw a very<BR>
> large WARNING to let you know that what you are doing can will<BR>
> potentially allow bad data into the database and that its<BR>
> effects only last for the duration of the session.<BR>
><BR>
> SELECT postgis_enable_parser_checks()<BR>
> - This will re-enable ALL checks performed by the parser. Note<BR>
> that all checks enabled will remain the default.<BR>
><BR>
><BR>
> The undocumented API:<BR>
><BR>
> SELECT postgis_parser_checks(int, int)<BR>
> - This will allow advanced developers the ability to specify the<BR>
> parser checks as 2 bitmaps: 1 for incoming geometries, and 1 for<BR>
> outgoing geometries (those generated by GEOS). It is designed<BR>
> for use and testing by developers only.<BR>
><BR>
><BR>
> Note that I have deliberately named these functions so that they are<BR>
> in the postgis_ namespace rather than the ST_ namespace, and so<BR>
> developers should be well aware that what they are doing is definitely<BR>
> outside of the OGC specification and that its behaviour is unique to<BR>
> PostGIS.<BR>
><BR>
> Once these changes have been committed, the final stage of the plan is<BR>
> to move shp2pgsql/pgsql2shp over to use liblwgeom and the new stored<BR>
> procedures (adding something like a --force option to trigger this<BR>
> behaviour).<BR>
><BR>
><BR>
> Thoughts?<BR>
><BR>
> Mark.<BR>
><BR>
_______________________________________________<BR>
postgis-devel mailing list<BR>
postgis-devel@postgis.refractions.net<BR>
<A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
<HTML><BODY><P><hr size=1></P>
<P><STRONG>
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.
</STRONG></P></BODY></HTML>
<P><hr size=1></P>
<P><STRONG><font size="2" color="339900"> Help make the earth a greener place. If at all possible resist printing this email and join us in saving paper. </p> <p> </font></STRONG></P>