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

FR: Support extension names not matching the crate names #1546

Open
netthier opened this issue Feb 9, 2024 · 2 comments
Open

FR: Support extension names not matching the crate names #1546

netthier opened this issue Feb 9, 2024 · 2 comments
Labels
build-sys Regarding the "build system" of pgrx which is split between cargo-pgrx, pg-sys, and sql-entity-graph cargo-pgrx enhancement New feature or request

Comments

@netthier
Copy link

netthier commented Feb 9, 2024

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.

@workingjubilee workingjubilee added enhancement New feature or request cargo-pgrx build-sys Regarding the "build system" of pgrx which is split between cargo-pgrx, pg-sys, and sql-entity-graph labels Feb 12, 2024
@workingjubilee
Copy link
Member

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:

pgrx/pgrx/src/lib.rs

Lines 272 to 285 in 3e530b6

macro_rules! pg_sql_graph_magic {
() => {
// A marker which must exist in the root of the extension.
#[doc(hidden)]
pub fn __pgrx_marker() -> $crate::pgrx_sql_entity_graph::ControlFile {
use ::core::convert::TryFrom;
let package_version = env!("CARGO_PKG_VERSION");
let context = include_str!(concat!(
env!("CARGO_MANIFEST_DIR"),
"/",
env!("CARGO_CRATE_NAME"),
".control"
))
.replace("@CARGO_VERSION@", package_version);

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

@eeeebbbbrrrr
Copy link
Contributor

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:

pgrx/pgrx/src/lib.rs

Lines 272 to 285 in 3e530b6

macro_rules! pg_sql_graph_magic {
() => {
// A marker which must exist in the root of the extension.
#[doc(hidden)]
pub fn __pgrx_marker() -> $crate::pgrx_sql_entity_graph::ControlFile {
use ::core::convert::TryFrom;
let package_version = env!("CARGO_PKG_VERSION");
let context = include_str!(concat!(
env!("CARGO_MANIFEST_DIR"),
"/",
env!("CARGO_CRATE_NAME"),
".control"
))
.replace("@CARGO_VERSION@", package_version);

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.

workingjubilee pushed a commit that referenced this issue Feb 29, 2024
The `pg_sql_graph_magic!()` did some shenanigans related to loading the
extension ".control" file at compile-time and embedded it in the
compiled artifact. This was convoluted and actually unnecessary as the
location where that information was used (in `schema.rs`) can easily
access the ".control" file at runtime.

This PR removes that macro and its usages.

The `fn __pgrx__marker()` function is still required, however. It's
necessary to ensure that the `rustc` build we do for the `pgrx_embed`
binary for schema generation properly links so that the other
(dynamically referenced) `__pgrx_internals_XXX` symbols can be found.
The function, however, is now a noop.

This is related to #1546, but is not a solution. It should just make
solving that request easier.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build-sys Regarding the "build system" of pgrx which is split between cargo-pgrx, pg-sys, and sql-entity-graph cargo-pgrx enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants