[postgis-tickets] [PostGIS] #3503: ST_ColorMap regress failing on PostgreSQL 9.6 debbie

[PostGIS]

#3503: ST_ColorMap regress failing on PostgreSQL 9.6 debbie
-----------------------+--------------------------------
  Reporter:  robe      |      Owner:  robe
      Type:  defect    |     Status:  closed
  Priority:  critical  |  Milestone:  PostGIS PostgreSQL
 Component:  raster    |    Version:  trunk
Resolution:  fixed     |   Keywords:
-----------------------+--------------------------------

Comment (by robe):

 For completeness, here is Tom's committ that fixed the issue:


 {{{
     Don't split up SRFs when choosing to postpone SELECT output
 expressions. (details)

 Commit d543170f2fdd6d9845aaf91dc0f6be7a2bf0d9e7 by Tom Lane

 Don't split up SRFs when choosing to postpone SELECT output expressions.
 In commit 9118d03a8cca3d97 we taught the planner to postpone evaluation
 of set-returning functions in a SELECT's targetlist until after any sort
 done to satisfy ORDER BY.  However, if we postpone some SRFs this way
 while others do not get postponed (because they're sort or group key
 columns) we will break the traditional behavior by which all SRFs in the
 tlist run in-step during ExecTargetList(), so that you get the least
 common multiple of their periods not the product.  Fix
 make_sort_input_target() so it will not split up SRF evaluation in such
 cases.
 There is still a hazard of similar odd behavior if there's a SRF in a
 grouping column and another one that isn't, but that was true before and
 we're just trying to preserve bug-compatibility with the traditional
 behavior.  This whole area is overdue to be rethought and reimplemented,
 but we'll try to avoid changing behavior until then.
 Per report from Regina Obe.
 }}}

--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/3503#comment:10>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.