-
Notifications
You must be signed in to change notification settings - Fork 543
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
Command history configuration/HISTFILE option #535
Comments
For me a history-file-per-database ability is a must. I connect to a lot of different databases and I don't want history from other DBs showing up when working with my current DB. This is going to keep me from using this great product. |
Adding my +1 for this as well as for |
Here's a dumb, hacky workaround for those who want history-file-per-database with the current release version of pgcli. If, like me, you formerly used the environment variable
To explain briefly: The above creates a new temporary config file that is the same as the actual pgcli config file, only with the The Create an alias or shell function incorporating the above approach, and you're good to go. A more convenient solution would be to create a shell function that extracts the db name (and maybe host, etc) from the command line, and incorporates that into the |
I am currently struggling switching among different databases. A per-database history would be neat |
I'd like to pick this four-years-ago feature request up. 😀 |
I have been thinking this feature for days. So here's what I want to do: pgcli allow user to set
Then, when you connect this db via See when you have a develop database on your machine, and another database on staging environment, you may want them share the same history file. You can set
I think we can read I also want to add a new option on |
@laixintao I like the idea of
what do you think? |
Good idea! Since it's a separate section I think we should only allow absolute path ( But I am worried that the section's name is the same as Line 65 in 7626d9a
|
Hah. I forgot that we have the same name already. You're right, it may be confusing. We better name the section differently. Maybe |
I wrote a demo pgclirc and support (Naming things are hard, I hope users can understand what those options/configs are used for, without contemplate...) |
Wild idea: maybe it would be nice to generalize this feature, to be able to set any configuration options per database? For example, dedicate a whole config section for a particular database. Or, even better, allow extending the default config file, so I can create separate config files per db containing the few differences I want to set, but all the common settings would still be loaded from the main config. This would be very useful, because you can then override some parameters when starting pgcli from commandline, and we surely don't want to add a CLI parameter for all of the config options there :) Example usecases:
edit: Another approach I just thought of would be to enable appending |
@quezak This sounds like a good solution for something that you envision will change a lot, and does not make much sense in config file. For existing options, we could support specifying them "standalone" (example: In general, when I try to decide where a new option should go, my thought process is something like this: To clarify, we currently don't have support for database-specific config file sections. But that would be a great feature to add. |
This flow is cool and makes sense to me. @quezak Isn't |
@laixintao |
In my psqlrc file, I have the following:
\set HISTFILE ~/.psql_history- :DBNAME
This allows for a history file per database I connect to, making it easy to get the history of commands for that database.
It would be nice if that were supported, ideally from parsing .psqlrc, to make switching easier.
Similarly, it would be nice if the history were done the same way as psql's (which is unfortunately not time stamped), again to ease transition and allow a new user to just start up pgcli and get their existing history.
The text was updated successfully, but these errors were encountered: