Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix/compatability with latest postgres #81

Merged
merged 2 commits into from
Jan 23, 2025

Conversation

pancost
Copy link
Collaborator

@pancost pancost commented Jan 22, 2025

PostgreSQL version 17 breaks the plugin (see issue #71)

Version 17 introduced the following:

Change functions to use a safe search_path during maintenance operations (Jeff Davis) § §
This prevents maintenance operations (ANALYZE, CLUSTER, CREATE INDEX, CREATE MATERIALIZED VIEW, REFRESH MATERIALIZED VIEW, REINDEX, or VACUUM) from performing unsafe access. Functions used by expression indexes and materialized views that need to reference non-default schemas must specify a search path during function creation.

For us this meant that functions that are part of a REFRESH MATERIALIZED VIEW operation like st_snap_poly_to_grid can no longer find PostGIS types (geometry) from the public schema because the path is temporarily changed to only include pg_catalog and pg_temp.

As suggested the solution is to set the 'extra' schema in the function definition

@pancost pancost added the bug Something isn't working label Jan 22, 2025
@pancost pancost requested a review from gioagu January 22, 2025 19:42
@gioagu
Copy link
Member

gioagu commented Jan 22, 2025

Thanks for looking it up!

Just one question: did you ensure that the SET search_path within the function has local scope? we do NOT want this set to be persistent once it exits the function, or once the transaction is finished.

I was just quickly reading here:

https://www.postgresql.org/docs/17/sql-set.html

Shouldn't it be a SET LOCAL ....?`

SET LOCAL search_path TO public, pg_catalog, pg_temp;`

I think this is what will do. Anyway, I did not have time to investigate much further...

@pancost
Copy link
Collaborator Author

pancost commented Jan 23, 2025

There is no "SET search_path within the function". The SET is on the function's definition.
There is difference between SET on function definition and SET in function runtime.

SET on runtime would require LOCAL to avoid persisting the change.
But that's not the case for SET on function creation

The SET clause causes the specified configuration parameter to be set to the specified value when the function is entered, and then restored to its prior value when the function exits (see CREATE FUNCTION)

I tested it and indeed after the function runs, the search_path reverts back to what it was before the function run

@gioagu
Copy link
Member

gioagu commented Jan 23, 2025

I see. Thanks!
Seems fine to me. I will merge then!

@gioagu gioagu merged commit e81ad5e into master Jan 23, 2025
@pancost pancost deleted the fix/compatability-with-latest-postgres branch January 23, 2025 19:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants