pgrx icon indicating copy to clipboard operation
pgrx copied to clipboard

FR: Support extension names not matching the crate names

Open netthier opened this issue 1 year ago • 2 comments

I have encountered an issue while developing a regular Rust library and a PostgreSQL extension module for it. Both are crates in the same workspace, named foo and foo_psql respectively. It seems that pgrx expects the .control file to always be named <CRATE_NAME>.control, meaning I have to create a foo_psql.control, leading to users having to execute CREATE EXTENSION foo_psql;. I would prefer if the extension were named foo instead, but am unsure how to achieve that (beyond manually renaming the .control file in the compiled artifacts), as naming the extension crate foo would lead to a conflict. I would also be happy if the .control file in my source code stayed named the same, but the file produced by cargo-pgrx commands was renamed.

netthier avatar Feb 09 '24 17:02 netthier

I asked @NotGyro to take a look at this. Unfortunately, it seems to be a bit tougher than expected. Implementing the patch in cargo-pgrx is easy, and that was done in https://github.com/NotGyro/pgrx/tree/extension-name-independent but pgrx features this, even on current develop:

https://github.com/pgcentralfoundation/pgrx/blob/3e530b6fdc99f2bbeab168dc48819a7810351254/pgrx/src/lib.rs#L272-L285

It's not clear how to work around this part so we'll probably be spinning our wheels for a bit on this.

workingjubilee avatar Feb 28 '24 19:02 workingjubilee

I asked @NotGyro to take a look at this. Unfortunately, it seems to be a bit tougher than expected. Implementing the patch in cargo-pgrx is easy, and that was done in https://github.com/NotGyro/pgrx/tree/extension-name-independent but pgrx features this, even on current develop:

https://github.com/pgcentralfoundation/pgrx/blob/3e530b6fdc99f2bbeab168dc48819a7810351254/pgrx/src/lib.rs#L272-L285

It's not clear how to work around this part so we'll probably be spinning our wheels for a bit on this.

We're addressing this mess in PR #1591. From there I suppose it should be fairly straightforward to figure out how to solve the OP's request.

eeeebbbbrrrr avatar Feb 29 '24 18:02 eeeebbbbrrrr