Cargo_edit version 0.13.2 - no longer has the function - get_latest_dependency - only available in 0.13.1

[MicroMouse25]

Hi,

Trying to install with the latest version of rustup v0.85.1 from following the crunchy guide for this pg extension comes to a failure due to the upgrade.rs for the compile for cargo prgx keeps pullng down cargo_edit_0.13.2.

This version has removed the function : get_latest_dependency from its functions list :

https://docs.rs/cargo-edit/latest/cargo_edit/index.html

It is present in cargo 0.13.1 and earlier, but the install keeps pulling the latest

Can the cargo prgx compile be updated to cope with the change in functions if cargo_edit 0.13.2 is identified or higher or the upgrade check is either removed or 0.13.1 module or earlier is downloaded for the cargo_pgrx complile.

If a workaroud piece of code can be provided for the cargo_edit to be place in the upgrade check or how to safely pass this to complete to cargo_pgrx install would be much appreciated.

Running RHEL v8 - 64bit

[MicroMouse25]

Have managed to install the component by find the Crate - cargo_edit and then updating the Cargo.lock that reference 0.13.2 whilst the Cargo.toml still referenced the 0.13.1, then deleted the registry folder from the .cargo home directory.

What I still don't understand I have pointed the cargo_prgx now to the pg_config location for the pg16 installation already on the boxes and varifying this it then creates a new data 16 directory inside .pgrx - I would of thought it would link into the existing data folder for the pg16 instance, but cannot see where this is specified and how to add in pg_parquet as when trying to use cargo_pgrx run or cargo_pgrx install --release after cd over to the correct data directly of my choice it complains of not finding the metadata.

Out of interest what is the user that is meant to be installing this : ROOT or Postgres user or changes over at certain points and the $ sign on the instruction for cargo_pgrx init --pg version $ produces an unexpected variable , but removing it doesn't at which point it reads the pg_config and creates this random .pgrx data directory, how is one meant to use pg_parquet with existing installs then as this seems just a poc and spins up its own instance seperate from existing instances.

[aykut-bozkurt]

You can check this part. Extension artifacts (.so and .sql scripts) are installed to the locations discovered by pg_config. cargo pgrx install does the work. cargo pgrx run does one more thing: create a separate data directory. Installation of the extension artifacts and initializing a data directory are separate things. You can run create extension pg_parquet on your existing or pgrx created data directory to have the extension working on your database after the installation.

[MicroMouse25]

Thanks for the response I was able to find a rpm of the pg_parquet over at pigsty and this worked perfectly to add the extension into our existing database instance. Can I suggest it may make sense to package up some rpms as other github do on their builds for some of the linux platforms if you hold the skills, assuming you do or you could link out to partners like pigz who have created rpm for linux from pg13 to pg17 of your underlying files. Just makes deployment easier. Apart from that the functionality pg_parquet adds is just what we wanted once we had it set up, so thanks for adding that missing ability