aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/geo_spgist.c
diff options
context:
space:
mode:
authorDavid Rowley <drowley@postgresql.org>2023-01-17 16:37:06 +1300
committerDavid Rowley <drowley@postgresql.org>2023-01-17 16:37:06 +1300
commitda5800d5fa636c6e10c9c98402d872c76aa1c8d0 (patch)
tree27e2bde3d8ed224ea4a1ad96eb6bb03a7cecb2be /src/backend/utils/adt/geo_spgist.c
parent52585f8f072ac187380f7e02183e87dcf6789ff0 (diff)
downloadpostgresql-da5800d5fa636c6e10c9c98402d872c76aa1c8d0.tar.gz
postgresql-da5800d5fa636c6e10c9c98402d872c76aa1c8d0.zip
Don't presort ORDER BY/DISTINCT Aggrefs with volatile functions
In 1349d2790, we gave the planner the ability to provide ORDER BY/DISTINCT Aggrefs with presorted input so that nodeAgg would not have to perform sorts during execution. That commit failed to properly consider the implications of if the Aggref had a volatile function in its ORDER BY/DISTINCT clause. As it happened, this resulted in an ERROR about the volatile function being missing from the targetlist. Here, instead of adding the volatile function to the targetlist, we just never consider an Aggref with a volatile function in its ORDER BY/DISTINCT clause when choosing which Aggrefs we should sort by. We do this as if we were to choose a plan which provided these aggregates with presorted input, then if there were many such aggregates which could all share the same sort order, then it may be surprising if they all shared the same sort sometimes and didn't at other times when some other set of aggregates were given presorted results. We can avoid this inconsistency by just never providing these volatile function aggregates with presorted input. Reported-by: Dean Rasheed Discussion: https://postgr.es/m/CAEZATCWETioXs5kY8vT6BVguY41_wD962VDk=u_Nvd7S1UXzuQ@mail.gmail.com
Diffstat (limited to 'src/backend/utils/adt/geo_spgist.c')
0 files changed, 0 insertions, 0 deletions