[postgis-devel] Use ofdeprecated functionsin non-deprecatedfunctions

[Kevin Neufeld]

Obe, Regina wrote:
> Kevin,
> 
> I still have reservations.
> 
> It gets a bit iffy
> later on down the line if we start deprecating auto-magic stuff I
> guess was part of my thinking.  I was also thinking someone coming along
> may not realize the distinction between using an sql function and a plpgsql
> function and arbitrarily copy the wrong approach thus accidentally 
> slowing down performance.
> 
> Now I think about it, those things would be easy to catch anyway.

Yes, agreed that we would have to come up with some alternative solution 
to deprecating auto-magic stuff, but that would be far, far off in the 
distant future.  I don't think there are any ST_* functions that need to 
be deprecated just yet.

> 
> Although if we put a notice in there wouldn't it always be spitting out 
> the NOTICE for each call which could potentially slow down older 
> applications.
> 
> Take the example of
> 
> SELECT Area(the_geom)
> FROM sometable
> 
> Wouldn't it spit out a notice for each call which could slow things down 
> a lot or maybe it doesn't work as I expect. In which case would be fine 
> with me. 
> 

Yes, your example would spit out a notice for every call to Area(), and 
yes, it would make things very slow, filling the logs, etc.  But, to me, 
this would be a preferable first step to simply removing Area() and 
break old apps cold.

I have no idea if we even want to remove the deprecated functions in the 
future (I thought there was talk on this earlier, but I can't seem to 
find it).  If we remove deprecated functions, it will break old apps and 
we would undoubtedly have to create a "restore_depreacted_functions" 
script so folks can upgrade to the latest PostGIS version and still use 
their old apps.  In which case, why would we even deprecate these 
functions in the first place.  Or maybe, for PostGIS, "deprecate" simply 
means "undocumented".

-- Kevin