[postgis-devel] geom_name

Thu Sep 7 14:05:34 PDT 2017

Yah Damn was my thinking too.  I'd just keep it as is and maybe if enough want, we can introduce the second CREATE AGGREGATE version that takes no geom_name in 2.5.

My desire for fewer functions is fighting with my desire to ease user land.

I'm kind of indifferent though, if you want to define a second CREATE AGGREGATE that takes no geom_name then go ahead.

We might as well keep the original as is so we don't break any existing code.

One other observation – 

ST_AsMVT is not being picked up as an agg function here

http://postgis.net/docs/manual-dev/PostGIS_Special_Functions_Index.html#PostGIS_Aggregate_Functions  

Because it has no "set"  in the arg

http://postgis.net/docs/manual-dev/ST_AsMVT.html

anyelement row

should be changed to

anyelement set row

sounds weird but oh well.

From: Paul Ramsey [mailto:pramsey at cleverelephant.ca] 
Sent: Thursday, September 07, 2017 4:59 PM
To: bjorn at wololo.org
Cc: Regina Obe <lr at pcorp.us>; PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] geom_name

On Sep 7, 2017, at 1:49 PM, Björn Harrtell <bjorn.harrtell at gmail.com <mailto:bjorn.harrtell at gmail.com> > wrote:

Most annoying agitation! Because it's backed with sound reasoning and clear improvement to current state.

So, I'm open to make these changes. It's now or never right.

However, one limiting factor is that I'm fairly certain aggregate functions do not support the DEFAULT keyword for parameters (affecting ST_AsMVT).

Damn.

You seem to be right. The raster aggregates show the pattern of multiple agg definitions to support different parameter patterns,  and extra transfns for each pattern. That’s probably required so that the back-end can match up the parameters of the aggregate to the parameters of the transfn to use the correct one. 

So the goal of having simpler userland signatures for the aggregates runs into causing a much uglier situation in the set-up scripts. The C code can probably remain simple, but it then looks much as it does now, with checks for NULL parameters and use of defaults in those cases.

I’m still kind of in favour of it, since a clean userland is nice. On the other hand, folks using these kinds of functions are probably using them in software (mapnik, geoserver, etc), not by hand, so they’ll write one (ugly) query once, then never look at it again.

Arguments pro and con?

P

/Björn

2017-09-07 22:39 GMT+02:00 Paul Ramsey <pramsey at cleverelephant.ca <mailto:pramsey at cleverelephant.ca> >:

Actually, no, I’d like to see signature changes… in particular, 

bytea ST_AsMVT(text layer_name, anyelement row,  int4 extent default 4096, text geom_name default NULL);

geometry ST_AsMVTGeom(geometry geom, box2d bounds, int4 extent default 4096, int4 buffer default 0, bool clip_geom default true);
bytea ST_AsGeobuf(anyelement row, text geom_name default NULL);

Then the presence of (geom_name == NULL) implies “automagically use the first geometry you find”

And the null checks on extent, buffer, clip_geom can be dropped since PgSQL will automatically in-fill the defaults

You don’t have to do the above, I’m just agitating for it.

Agitate, agitate.

P.

On Sep 7, 2017, at 1:34 PM, Björn Harrtell <bjorn.harrtell at gmail.com <mailto:bjorn.harrtell at gmail.com> > wrote:

So we are agreed that there will be no signature change? Instead I will work towards an implementation and documentation change for geom_name to the following:

"geom_name is the name of the geometry column in the row data. If NULL it will default to use the first geometry column in the row data."

/Björn

2017-09-07 21:08 GMT+02:00 Paul Ramsey <pramsey at cleverelephant.ca <mailto:pramsey at cleverelephant.ca> >:

Yes, take the first one unless the geom_name is provided. So geom_name would default to NULL and NULL would mean “the first one you find"

P

On Sep 7, 2017, at 12:06 PM, Regina Obe <lr at pcorp.us <mailto:lr at pcorp.us> > wrote:

Just to add to this to make sure I'm following:

For this question:

> Also, a bit late in the day, but why the text parameter "geom_name" in these various signatures, instead of automagically finding it in the row?

> ?

> P

Is it ever possible that an MVT row could have more than one geometry column.  I assume so.  If so I think it might be good to keep the geom_name field though perhaps make it a default option and in that case it picks the first one it finds.  Similar to how we do pgsql2shp where you can explicitly set the geometry column or have pgsql2shp do it's thing and just pick the first one it finds.

Thanks,

Regina

From: Regina Obe [ <mailto:lr at pcorp.us> mailto:lr at pcorp.us] 
Sent: Thursday, September 07, 2017 2:57 PM
To: 'PostGIS Development Discussion' < <mailto:postgis-devel at lists.osgeo.org> postgis-devel at lists.osgeo.org>; 'Björn Harrtell' < <mailto:bjorn at wololo.org> bjorn at wololo.org>
Cc: 'Paul Ramsey' < <mailto:pramsey at cleverelephant.ca> pramsey at cleverelephant.ca>
Subject: RE: [postgis-devel] geom_name

> We should ask about API changing, I'm sure Regina would say we're done, which effectively means done-for-all-time, since changing public function signatures is basically impossible one they are done.

> P

I'm fine with you changing the API now before final 2.4.0 release.  I promised no new functions, not no new API changes to new 2.4 functions.

I think it would be good to drop the old signature in the postgis_drop_before.sql  since some people have already started using the MVT functions.

If it impacts existing code, we should also put in BREAKING CHANGE for postgis -2.4.0  the change so people are warned and know how to change their code if they were using an earlier postgis 2.4.0dev

Thanks,

Regina

On Thu, Sep 7, 2017 at 10:45 AM, Björn Harrtell < <mailto:bjorn.harrtell at gmail.com> bjorn.harrtell at gmail.com> wrote:

Hi Paul,

No good reason except that I couldn't find out a deterministic way to find it and put it out of my mind after that. :(

With some guidance I'll be happy to revise the API if it's not too late at this point.

/Björn

2017-09-07 19:41 GMT+02:00 Paul Ramsey < <mailto:pramsey at cleverelephant.ca> pramsey at cleverelephant.ca>:

Also, a bit late in the day, but why the text parameter "geom_name" in these various signatures, instead of automagically finding it in the row?

?

P

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170907/9277ebb3/attachment.html>