Deprecate pgrx::hooks without replacement#1752
Conversation
|
As far as I understand, this is going to break any PGRX extension that defines PostgresQL hooks ? Seems like a radical choice, given that there may be some of these hook-based extensions currently in production... What would be the best approach for them ? Staying in version 0.11 indefinetely with no support for Postgres 17+ or maybe something like |
|
@daamien you can just |
|
My only hesitation for committing this at the moment is currently I'm also using deprecations to communicate about other things that can be effectively replaced, so I am reluctant to fill the deprecation notices with even more. |
|
I've decided I'm only going to merge this deprecation notice after I cut 0.12.0 proper, as otherwise a bunch of useful deprecation notices will be shadowed by one kinda useless one (I feel the request is a bit unfair, even if it's true it's more sound code). |
575dc94 to
a217272
Compare
|
To keep some decision-making trail, is it fair to note that #1749 would be a good reference for the problems discussed here? |
Even if we could fix this with internal refactors, I think it's a sufficiently bad pattern, and sufficiently hard to reason about the soundness of it, that we should just tell people to drop this API.
Even if we could fix this with internal refactors, I think it's a sufficiently bad pattern, and sufficiently hard to reason about the soundness of it, that we should just tell people to drop this API.