Deprecation Warnings inside Aggregates

[pramsey]

I’ve found a number of deprecation changes that are going to have substantial performance penalties and are not really useful for their purpose of warning users:

​https://github.com/postgis/postgis/blob/svn-trunk/postgis/postgis.sql.in#L3461

Basically, they are functions underneath the ST_Extent aggregate. They are not meant to be called by users (we could un-document them, for example) they are meant to support the aggregates. We can leave the deprecation warnings in place, if we like, but we need to stop calling them ourselves inside the aggregates.

[pramsey]

Fixed at r13535, reduced query time for st_extent over large table by factor of 9x.

[robe]

Weren't we also going to introduce a GUC to disable these warnings?

I know strk doesn't want to give that option, but it is a performance issue for many people especially if they need to support multiple versions of PostGIS on there system.

Case in point, pgRouting has 2 deprecation warnings when I test against PostGIS 2.2. I don't think its a trivial exercise for them to change their code, especially since they need to support PostGIS 2.0, which predates some of these deprecations.

[pramsey]

We didn't have warnings when we went to 2.0, we just moved the suckers into legacy.sql, what's wrong w/ the brutal old way?

[robe]

Cause when we did that we were going from major to major so it was a good window to be brutal. I regret not finishing all that cleanup in 2.0

Now we are going from minor to minor so people expect their code to work across all variants of 2.* if they are using 2.0 only constructs.