[4.0.0 future major release] postgresql_info: remove the db alias

[Andersson007]

[4.0.0] postgresql_info: remove the db alias when in 4.0.0 release

The parameter was deprecated in #800

[toydarian]

There are also a few things in the user-module marked for deletion in 4.0.0. Should we remove those as well now?

[Andersson007]

There are also a few things in the user-module marked for deletion in 4.0.0. Should we remove those as well now?

@toydarian do you mean the same db parameter? if yes, what other folks think, should we replace it with login_db? cc @hunleyd

[toydarian]

No, I think it is mostly the priv stuff that was moved to its own module

[Andersson007]

@toydarian yes, we should remove it (as well as do other stuff in milestone 4.0.0), but not right now. we do it when releasing 4.0.0 not earlier than in late May (after next Ansible major version is released to minimize the impact of our breaking changes on users) or better even later. We haven't planned it yet.

My question is relevant about db in postgresql_user

[toydarian]

Ah okay, sorry, I thought that release was already ongoing.

About the db alias: I'm a fan of having things consistent, so if we do that we should do it everywhere.
This is the current state in the user-module: db=dict(type='str', default='', aliases=['login_db']),

[hunleyd]

i'm all for making login_* the actual param across the collection and making the non login_* the alias (and deprecated). we have an internal rule at $dayjob to always use the login_* version and it makes the code so much more readable and self-documenting

[Andersson007]

Cool, thanks for your feedback folks, I'm also a fan of consistency.
Does anybody want to help with opening similar PRs?

[toydarian]

Does anybody want to help with opening #800 PRs?

I can help

[Andersson007]

@toydarian great, thanks!
just a fyi: i'm off next week, so folks don't wait for my reviews

[toydarian]

Do you guys think, that we do that in every module?

I see a slight difference here. For example in postgresql_user, the db/login_db is actually only used for login, as the user is independent of the database. But in postgresql_table, the db/login_db is the database where the table is actually created in. So in that case, the parameter has a different significance and calling it login_db can be misleading.

[hunleyd]

But in postgresql_table, the db/login_db is the database where the table is actually created in. So in that case, the parameter has a different significance and calling it login_db can be misleading.

you can't create a table in a database you're not logged into, right? so it's still the login_db

[toydarian]

you can't create a table in a database you're not logged into, right? so it's still the login_db

Sure, but that is not my point. My point is, that for postgresql_user and postgresql_info, the login_db is only used for login and not changed, but in postgresql_table the database is actually changed (has a table added/removed etc), while the name login_db suggests it is only used for login.
In the postgresql_db module, we have name (alias db) for the database that is modified, but the login_db is called maintenance_db. All very confusing.

I honestly don't have a strong opinion on this, every option is fine for me.

[hunleyd]

ISTM that consistency across all the modules should be a goal of the collection with the various login_* parameters referring only to the initial connectivity (who do i login as, to which db, etc) and then other parameters (as needed) for where 'the thing' is done.

But I defer to group consensus.

[keithf4]

ISTM that consistency across all the modules should be a goal of the collection with the various login_* parameters referring only to the initial connectivity (who do i login as, to which db, etc) and then other parameters (as needed) for where 'the thing' is done.

But I defer to group consensus.

This makes the most sense to me.