8000 Do not use typedefs to hide that things are pointers by AndersAstrand · Pull Request #342 · percona/postgres · GitHub
[go: up one dir, main page]

Skip to content

Do no 8000 t use typedefs to hide that things are pointers #342

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

Open
wants to merge 1 commit into
base: TDE_REL_17_STABLE
Choose a base branch
from

Conversation

AndersAstrand
Copy link
Collaborator

This suggestion renames TDESMgrRelationData to TDESMgrRelation and removes the previous typedef that held that name. I think the code is much easier to read if we don't try to hide that something is a pointer using typedefs.

The pointer hiding typedef is a common postgres code pattern however, so I understand if not everyone is on-board with this idea for consistency with the core code, but I though I should at least bring it up for discussion 🙂.

And also remove the typedef that previously held the name
TDESMgrRelation. This typedef hides the pointer-ness of things and only
serves to make the code harder to read.
@codecov-commenter
Copy link

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.49%. Comparing base (2dbb8d8) to head (1ffd139).

❌ Your project status has failed because the head coverage (80.49%) is below the target coverage (90.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files
@@                  Coverage Diff                  @@
##           TDE_REL_17_STABLE     #342      +/-   ##
=====================================================
- Coverage              80.50%   80.49%   -0.01%     
=====================================================
  Files                     22       22              
  Lines                   2606     2605       -1     
  Branches                 399      398       -1     
=====================================================
- Hits                    2098     2097       -1     
  Misses                   430      430              
  Partials                  78       78              
Components Coverage Δ
access 82.95% <ø> (ø)
catalog 87.55% <ø> (ø)
common 91.80% <ø> (ø)
encryption 75.70% <ø> (ø)
keyring 72.00% <ø> (ø)
src 66.74% <ø> (ø)
smgr 97.27% <100.00%> (-0.03%) ⬇️
transam ∅ <ø> (∅)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Member
@dAdAbird dAdAbird left a comment

Choose a reason for hiding this comment

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

I agree. This way (w/o hidden pointers) the code is more obvious and easier to reason about.

Btw, is there any justification behind that practice in the core? Or it's just a habit?

@jeltz
Copy link
Collaborator
jeltz commented May 20, 2025

It is a weird habit from the PG project which is just annoying and many of the devs disagree with. I believe it is based on some idea that some data structures should be opaque and you just treat them as a handle. Let's do this! I hate these!

@AndersAstrand
Copy link
Collaborator Author
AndersAstrand commented May 20, 2025

Since we're 3/5 devs in the team liking this I'll convert it to a proper PR 😄

But won't merge if @dutow or @artemgavrilov hates it ofc.

@AndersAstrand AndersAstrand marked this pull request as ready for review May 20, 2025 14:35
@AndersAstrand AndersAstrand requested a review from dutow as a code owner May 20, 2025 14:35
@AndersAstrand AndersAstrand changed the title IDEA: Do not use typedefs to hide that things are pointers Do not use typedefs to hide that things are pointers May 20, 2025
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.

4 participants
0