[postgis-devel] Deprecation Warnings

[Paul Ramsey]

Although, to answer myself, if we're doing that, is it so bad to just
keep the damn things around? the point of removing them is....
*removing* them. So they don't have to be thougth about anymore.

P.

On Fri, Jan 23, 2009 at 2:30 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
> Right. Not even wrappers, just breaking the install into postgis.sql
> and postgis_legacy.sql...
>
> P
>
> On Fri, Jan 23, 2009 at 2:25 PM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
>> 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.
>>
>> 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.
>>
>> 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.
>>
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net on behalf of Obe, Regina
>> Sent: Fri 1/23/2009 5:06 PM
>> To: PostGIS Development Discussion
>> Subject: RE: [postgis-devel] Deprecation Warnings
>>
>> +2
>>
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net on behalf of David
>> William Bitner
>> Sent: Fri 1/23/2009 4:51 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Deprecation Warnings
>>
>> +1, I like Cake.
>>
>> On Fri, Jan 23, 2009 at 2:59 PM, Kevin Neufeld
>> <kneufeld at refractions.net>wrote:
>>
>>> What if we deprecate the functions as you suggest (and eventually remove
>>> them), but provide a sql script that will reinstate them as wrappers to
>>> the
>>> ST_* methods.  That way, folks can have their cake and eat it too ...
>>> upgrade to the latest version without breaking their apps.
>>>
>>> -- Kevin
>>>
>>>
>>> Paul Ramsey wrote:
>>>
>>>> Could we use the function creation option
>>>>
>>>> SET configuration_parameter { TO value | = value | FROM CURRENT }
>>>>
>>>> to, for example, set postgis_deprecated to true?
>>>> Then in the function, we could warn on deprecation. So the same
>>>> backend to intersects() could be used by several function names, but
>>>> only some would raise deprecation warnings.
>>>>
>>>> Or do we want to continue our gentle regime of letting the old names
>>>> live in quite obscurity?
>>>>
>>>> P.
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>
>>
>>
>> --
>> ************************************
>> David William Bitner
>>
>>
>>
>>
>> -----------------------------------------
>> 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.
>>
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>