[postgis-devel] Function Removal

[Paul Ramsey]

> On Dec 16, 2020, at 3:55 PM, Bruce Rindahl <bruce.rindahl at gmail.com> wrote:
> 
> Right now Select ST_AsText(ST_MakePoint(1,2,4326)) returns POINT Z (1 2 4326)
> Are we going to have to cast the input every time to make sure it's a SRID?  That might be more confusing than ST_SetSRID(ST_MakePoint())

It's not a cast, it's a named parameter, and yes you'll have to use it. 

SELECT ST_AsEWKT(ST_Point(1, 2, srid => 4326))  returns SRID=4326;POINT(1 2)

Since they've come in we've really under-used named parameters. Some of that because of legacy, some of it because of mental inertia. But for these kinds of things they seem pretty ideal to me. Mean what you say, say what you mean, have what your parameters mean be clear instead of opaque. A good habit, all in all.

P

> 
> On Wed, Dec 16, 2020 at 11:41 AM Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> I feel like we've been over this before, but I ran into it again and I'm wondering what we think our best practice should be.
> 
> The issue is the removal of stacked multi-parameter functions. We have:
> 
>   CREATE FUNCTION ST_MakePoint(float8, float8)
>   CREATE FUNCTION ST_MakePoint(float8, float8, float8)
>   CREATE FUNCTION ST_MakePoint(float8, float8, float8, float8)
> 
> What's missing here? A place to set the SRID! So we constantly have this formation:
> 
>   ST_SetSRID(ST_MakePoint(...), ...)
> 
> Which is, let's face it, ugly. So being a smart boy I thought:
> 
>   CREATE FUNCTION ST_MakePoint(x float8, y float8, z float8 default null, m float8 default null, srid integer default null)
> 
> And then I updated the underlying C function to handle the nulls, and it works wonderfully:
> 
>   postgis=# select st_asewkt(ST_MakePoint(1, 2, srid => 123));
>   SRID=123;POINT(1 2)
> 
> Except, unfortunately now the old form is broken.
> 
>   postgis=# select st_asewkt(ST_MakePoint(1.2, 2.33)); 
>   ERROR:  function st_makepoint(double precision, double precision) is not unique
>   HINT:  Could not choose a best candidate function. You might need to add explicit type casts.
> 
> Yeah, it could be either my new one or the two-parameter form of the old one.
> 
> The obvious fix would be to remove the old signatures at the same time as adding the new one, but as I recall this leads to upgrade issues? This is where my memory is failing. I know (a) a single signature with defaults and argument names is nicer and cleaner and also (b) every time I've done it there's been some kind of an outcry / mess.
> 
> Any help, thoughts?
> 
> P
> _______________________________________________
> 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