[postgis-devel] geom_name

Thu Sep 7 14:39:15 PDT 2017

For those with an over-riding interest in such things, I tracked down the
question of aggregates with default arguments and the trail ends here about
7 years ago

http://www.postgresql-archive.org/Drop-one-argument-string-agg-was-Re-BUGS-string-agg-delimiter-having-no-effect-with-order-by-td2264527.html#a2264750

Basically Tom removed a multi-argument version of string_agg (I didn't
quite grok the reasons *why* it was causing problems for pg_upgrade...) and
stated that so doing would also preclude having aggregates with defaults.

The catalog structures are perfectly amenable to aggregates with defaults,
as they ride along in the same pg_proc catalog as ordinary functions. But
it looks like there's some deeper reasons they are difficult too.

ATB,

P

On Thu, Sep 7, 2017 at 2:14 PM, Regina Obe <lr at pcorp.us> wrote:

> I was hoping to get an RC out like by mid / late next week.
>
>
>
> To beat PostgreSQL 10 RC planned 9/14 launch
>
>
>
> https://www.postgresql.org/message-id/26618.1503689851@sss.pgh.pa.us
>
>
>
>
>
> So sooner the better.  I think once we release RC we really shouldn't even
> be making changes like this anymore that are user facing.
>
>
>
>
>
> Thanks,
>
> Regina
>
>
>
> *From:* Björn Harrtell [mailto:bjorn.harrtell at gmail.com]
> *Sent:* Thursday, September 07, 2017 5:06 PM
> *To:* Paul Ramsey <pramsey at cleverelephant.ca>
> *Cc:* Regina Obe <lr at pcorp.us>; PostGIS Development Discussion <
> postgis-devel at lists.osgeo.org>
> *Subject:* Re: [postgis-devel] geom_name
>
>
>
> I'm pro multiple agg definitions to get this as nice as possible. After
> all it's just two additional variants as ST_AsMVTGeom is not an aggregate.
>
>
>
> Do I get a deadline?
>
>
> /Björn
>
>
>
> 2017-09-07 22:59 GMT+02:00 Paul Ramsey <pramsey at cleverelephant.ca>:
>
>
>
> On Sep 7, 2017, at 1:49 PM, Björn Harrtell <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>:
>
> 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>
> 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>:
>
>
>
> 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> 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 <lr at pcorp.us>]
> *Sent:* Thursday, September 07, 2017 2:57 PM
> *To:* 'PostGIS Development Discussion' <postgis-devel at lists.osgeo.org>;
> 'Björn Harrtell' <bjorn at wololo.org>
> *Cc:* 'Paul Ramsey' <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 <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 <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/123d96a0/attachment.html>