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). |
workingjubilee
force-pushed
the
deprecate-hooks-api-without-replacement
branch
from
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.