<!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] Deprecation Warnings</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Hmm although it really wouldn't be deprecate -- it would be lets remove them and allow people to reinstate them if they want as Kevin suggested.<BR>
<BR>
Personally I don't care for warnings -- either keep it or get rid of it. Warnings sounds like a lot of wasted log space which will probably only be seen by logs and potentially mysteriously slow down applications in the process.<BR>
<BR>
Though I guess we must think of the children (Mapserver, GeoServer and ZigGIS and so forth which may be using the old names). But then I suppose anyone using apps relying on deprecated names would just install the wrapper patch.<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Obe, Regina<BR>
Sent: Fri 1/23/2009 5:06 PM<BR>
To: PostGIS Development Discussion<BR>
Subject: RE: [postgis-devel] Deprecation Warnings<BR>
<BR>
+2<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of David William Bitner<BR>
Sent: Fri 1/23/2009 4:51 PM<BR>
To: PostGIS Development Discussion<BR>
Subject: Re: [postgis-devel] Deprecation Warnings<BR>
<BR>
+1, I like Cake.<BR>
<BR>
On Fri, Jan 23, 2009 at 2:59 PM, Kevin Neufeld <kneufeld@refractions.net>wrote:<BR>
<BR>
> What if we deprecate the functions as you suggest (and eventually remove<BR>
> them), but provide a sql script that will reinstate them as wrappers to the<BR>
> ST_* methods. That way, folks can have their cake and eat it too ...<BR>
> upgrade to the latest version without breaking their apps.<BR>
><BR>
> -- Kevin<BR>
><BR>
><BR>
> Paul Ramsey wrote:<BR>
><BR>
>> Could we use the function creation option<BR>
>><BR>
>> SET configuration_parameter { TO value | = value | FROM CURRENT }<BR>
>><BR>
>> to, for example, set postgis_deprecated to true?<BR>
>> Then in the function, we could warn on deprecation. So the same<BR>
>> backend to intersects() could be used by several function names, but<BR>
>> only some would raise deprecation warnings.<BR>
>><BR>
>> Or do we want to continue our gentle regime of letting the old names<BR>
>> live in quite obscurity?<BR>
>><BR>
>> P.<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>
> _______________________________________________<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>
<BR>
<BR>
<BR>
--<BR>
************************************<BR>
David William Bitner<BR>
<BR>
<BR>
<BR>
<BR>
-----------------------------------------<BR>
The substance of this message, including any attachments, may be<BR>
confidential, legally privileged and/or exempt from disclosure<BR>
pursuant to Massachusetts law. It is intended<BR>
solely for the addressee. If you received this in error, please<BR>
contact the sender and delete the material from any computer.<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>