Opened 6 years ago
Closed 6 years ago
#4299 closed defect (fixed)
st_generatepoints declared IMMUTABLE
Reported by: | pnorman | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | |
Component: | postgis | Version: | 2.3.x |
Keywords: | Cc: |
Description
On my 2.3 system st_generatepoints
is declared as IMMUTABLE
. This is only valid for functions that always generate the same output given the same parameters. Random functions should be VOLATILE because they can give different results each time they are called.
On a closely related matter, it is also marked as PARALLEL SAFE
, which might not be true - https://www.postgresql.org/docs/11/parallel-safety.html says that random
is PARALLEL RESTRICTED
because it accesses "miscellaneous backend-local state which the system cannot synchronize across workers" and the same might be true for st_generatepoints
This originates from https://lists.osgeo.org/pipermail/postgis-devel/attachments/20190115/292e0a64/attachment.html
Change History (4)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
Another reason for the behavior in the email is because the RNG is initialized with srand(time(NULL));
, which means if you re-run the query multiple times within one clock second, you will get the same results. (Try it, but you need to be quick!)
I'll try to address this ticket with #4304
comment:3 by , 6 years ago
See https://github.com/postgis/postgis/pull/365 which attempts to implement these changes.
https://postgis.net/docs/ST_GeneratePoints.html says "ST_GeneratePoints generates pseudo-random points until the requested number are found within the input area". There is no guarantee that sequence will be the same or not the same each time. IMMUTABLE only affects caching in Postgres as for now, and per current documentation it's okay to cache ST_GeneratePoints output for the same polygon. Will a note about this behavior be sufficient?