You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Review the public API signatures to determine where optional configuration should be keyword-only. This should cover more than postgresql_proc and postgresql_noproc; include the public client API as well.
DatabaseJanitor already uses keyword-only arguments and can serve as an established precedent.
Rationale
Public factory signatures currently allow a growing number of optional positional arguments. Adding options such as load_autocommit can either rebind an existing positional argument or make calls hard to read. A consistent keyword-only boundary would preserve clearly positional connection identity inputs while preventing future ambiguity.
This is intentionally a broader API-design and backwards-compatibility decision, not an incidental follow-up to the autocommit implementation.
Affected areas
Public postgresql_proc factory API
Public postgresql_noproc factory API
Public client API
Related documentation, type signatures, and compatibility/newsfragment policy
Acceptance criteria
Inventory the relevant public factory and client call signatures and current positional usage expectations.
Decide and document an API policy for which parameters remain positional and where keyword-only boundaries should be introduced.
Keep DatabaseJanitor's existing keyword-only design in mind for consistency.
If a change is adopted, apply it consistently across the chosen public APIs, update documentation and tests, and include the appropriate breaking-change newsfragment.
Summary
Review the public API signatures to determine where optional configuration should be keyword-only. This should cover more than
postgresql_procandpostgresql_noproc; include the public client API as well.DatabaseJanitoralready uses keyword-only arguments and can serve as an established precedent.Rationale
Public factory signatures currently allow a growing number of optional positional arguments. Adding options such as
load_autocommitcan either rebind an existing positional argument or make calls hard to read. A consistent keyword-only boundary would preserve clearly positional connection identity inputs while preventing future ambiguity.This is intentionally a broader API-design and backwards-compatibility decision, not an incidental follow-up to the autocommit implementation.
Affected areas
postgresql_procfactory APIpostgresql_noprocfactory APIAcceptance criteria
DatabaseJanitor's existing keyword-only design in mind for consistency.Context
Requested by @fizyk in review discussion for #1383.