pgrx
                                
                                
                                
                                    pgrx copied to clipboard
                            
                            
                            
                        FR: Support extension names not matching the crate names
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.
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.
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.