GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
When investigating for #7564, I found potentially bug. In database.yml, we use not charset but encoding.
Use configuration['encoding'], because database configuration use not…
… charset but encoding.
That's weird, I thought it could be due to the refactoring/extraction, but 3-2 uses the same in databases.rake, which is confusing. Other databases such as postgresql also name it encoding. I think you're right, we should stick with encoding, since it's the correct option being generated by the application templates, but I'm wondering how it's being used all this time without being noticed =(.
Maybe because nobody use this option. Also, as far I remember I think that @kennyj added the encoding option to PostgreSQL only to master.
@carlosantoniodasilva @rafaelfranca I added the collation option to PostgreSQL only to master (not encoding) :)
I also guess nobody use this option. Because in many case, we use utf-8 which is default.
Right. Sorry for my bad memory.
I'll merge this one. Could you add a changelog entry and also create a pull request to 3-2-stable?
Backported #7572 to 3-2-stable. Use config['encoding'], because datab…
…ase configuration use not charset but encoding.
@rafaelfranca I submited to 3-2-stable, and I added a changelog entry to 3-2-stable.
I think I don't need to add a changelog entry to master. Ok?
I'll close this PR, because this diff is added to #7564.
Merge pull request #7603 from kennyj/fix_charset_vs_encoding_32
Backported #7572 to 3-2-stable. Use config['encoding'], because database configuration use not charset but encoding.