Skip to content

Conversation

@incrypto32
Copy link
Contributor

This PR aims to make the arguments for initdb command configurable.

@boustrophedon
Copy link
Owner

Thanks for using pgtemp! This looks fine but I'm wondering in what situations you need to set the config via initdb and not at runtime via the with_config_param option. Incidentally it looks like I intended initially to use the server_configs with both initdb and the actual postgres execution but didn't / forgot to.

Would it make more sense to set the existing configs on initdb as well, or is there a usecase where they need to be separate? e.g. testing what happens when a db is created one way but then run with extra options later?

@boustrophedon
Copy link
Owner

Do the test failures occur for you locally? If not it could be an issue with the version of postgres in github CI

@incrypto32
Copy link
Contributor Author

Hey @boustrophedon a use case i can think of is to set the locale which is not possible to set in the server configuration.

As for the tests im afk right now, will check and report back if it works locally.

@boustrophedon
Copy link
Owner

That makes sense and is indeed stated in the documentation https://www.postgresql.org/docs/current/locale.html

Some locale categories must have their values fixed when the database is created. You can use different settings for different databases, but once a database is created, you cannot change them for that database anymore. LC_COLLATE and LC_CTYPE are these categories

I took another look at the test and the output failure, lc_collate and lc_ctype are probably supposed to be in allcaps.

src/lib.rs Outdated
/// Other server configuration data to be set in `postgresql.conf` via `initdb -c`
pub server_configs: HashMap<String, String>,
/// Configuration parameters to be passed to `initdb` command
pub initdb_configs: HashMap<String, String>,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you change this and the function name to be arguments or args? e.g. initdb_args and with_initdb_arg, and update the documentation to mention they're direct arguments to the initdb binary (and not postgres configs that get written to the conf file, as with -c)

@incrypto32 incrypto32 requested a review from boustrophedon May 6, 2025 13:34
@boustrophedon
Copy link
Owner

Hi, it looks good except that the test is still failing because the method name wasn't changed in the test.

Could you squash all the commits as well when you have the tests passing? Thanks!

@incrypto32
Copy link
Contributor Author

@boustrophedon just fixed all of it, Ran cargo test this time 😅 and sorry for earlier.
Looks like all test passes.

@LNSD
Copy link

LNSD commented Nov 5, 2025

Hi @boustrophedon, is there any work pending to merge this PR? Can I help?

@boustrophedon
Copy link
Owner

Hi, I've been busy with work. This looks good except the commits still need to be squashed.

@incrypto32
Copy link
Contributor Author

@boustrophedon I just squashed the commits

@boustrophedon boustrophedon merged commit f0aae1a into boustrophedon:master Nov 6, 2025
@boustrophedon
Copy link
Owner

thread 'buider_setters' panicked at tests/basic_operations.rs:108:10:
failed to execute LC_COLLATE query: Database(PgDatabaseError { severity: Error, code: "42704", message: "unrecognized configuration parameter \"lc_collate\"", detail: None, hint: None, position: None, where: None, schema: None, table: None, column: None, data_type: None, constraint: None, file: Some("guc.c"), line: Some(1241), routine: Some("find_option") })
stack backtrace:

well, that's not good https://github.com/boustrophedon/pgtemp/actions/runs/19150293475/job/54738465810

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants