[postgis-devel] Function Removal

[Bruce Rindahl]

One thing leads to another.
Looks good to me

On Thu, Dec 17, 2020 at 9:36 AM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

>
>
> > 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
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20201217/669ad402/attachment.html>