[postgis-devel] Aggregate STYPE

[Regina Obe]

My vote do the DROP CASCADE in the after.sql.

My thinking is it's fairly safe to do it, because all the critical things that would be tied to people's views and what not will be in the 

CREATE AGGs...

So if they have stuff tied to those, the upgrade will fail before it ever gets to the DROP CASCADE call.

Only case I can think of where it might be an issue if someone built their own custom functions and aggs using pgis_abs, which I suspect is few if any people.
I suppose if you were concerned, for the existence of such people, you could do a catalog query to determine what else is dependent on pgis_abs before you pull the trigger.

-----Original Message-----
From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Paul Ramsey
Sent: Tuesday, March 06, 2018 2:52 PM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] Aggregate STYPE

A little testing shows that there's no way to drop the in/out functions and type in an "acceptable" order, the only option is to drop the type and ask it to CASCADE away the dependent functions at the same time.

On Tue, Mar 6, 2018 at 11:47 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> Actually, I think it's even more awful, all the transfns that have
> func(pgis_abs) signatures will still be around, since the upgrade will 
> have not replaced them, but rather supplemented them with
> func(internal) variants. So all the old transfns will need to be 
> explicitly dropped. Do we have any example of how the chicken/egg 
> problem of dropping a type is supposed to work?
> P
>
> On Tue, Mar 6, 2018 at 11:15 AM, Sandro Santilli <strk at kbt.io> wrote:
>> On Mon, Mar 05, 2018 at 10:21:14AM -0800, Paul Ramsey wrote:
>>> OK, I think I've done all the due-diligence in
>>> https://trac.osgeo.org/postgis/ticket/4035
>>
>> I think the order of the DROPs you added won't work:
>>
>>   -- Old accum aggregate support type, removed in 2.5.0
>>   DROP FUNCTION IF EXISTS pgis_abs_in(cstring);
>>   DROP FUNCTION IF EXISTS pgis_abs_out(pgis_abs);
>>   DROP TYPE IF EXISTS pgis_abs;
>>
>> I'd think the first two DROP FUNCTION would raise an exception about 
>> type pgis_abs requiring them (so can't drop). Did you try the upgrade 
>> ?
>>
>> --strk;
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-devel