[postgis-devel] Aggregate STYPE -C SQL API breakage

[Paul Ramsey]

So we have a new backwards compatibility requirement in 2.x releases?
Uh, alright.
Actually the C signatures stayed the same, interestingly enough, so I
bet a 2.5 .so is *almost* compatible with a 2.4 SQL install, with the
exception of the transfn which now allocates the pgis_abs in aggregate
memory context. That *might* cause memory bloat I'm not 100% sure.
P.

On Tue, Mar 6, 2018 at 10:42 PM, Regina Obe <lr at pcorp.us> wrote:
> It just occurred to me while I was dreaming of upgrading a 1 TB database, that this will probably break my ability to just swap out old library with new so I don't have to install the newer PostGIS
> In my older PostgreSQL.  I'll test live to confirm my suspicion later.
>
> While we are enjoying this exercise, you want start a rehearsal run of maintaining C SQL API versions before we go to 3.0.
>
> That would mean putting back the pgis_abs support functions but stubbing them with an error function.
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Paul Ramsey
> Sent: Tuesday, March 06, 2018 2:48 PM
> To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> Subject: Re: [postgis-devel] Aggregate STYPE
>
> 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
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel