Skip to content

fix: correct style issues and bugs in ivy_guc.c#3

Open
OreoYang wants to merge 1 commit intomasterfrom
test/claude-code-settings
Open

fix: correct style issues and bugs in ivy_guc.c#3
OreoYang wants to merge 1 commit intomasterfrom
test/claude-code-settings

Conversation

@OreoYang
Copy link
Owner

Summary

This PR fixes several style issues and bugs in src/backend/utils/misc/ivy_guc.c:

  • Fixed typo: Changed "shown as blow" to "shown below" in comment (line 59)
  • Fixed duplicate period: Removed extra period in error hint message (line 479)
  • Fixed null terminator bug: Corrected placement of null terminator in nls_case_conversion function (lines 537, 545)
    • The null terminator was being set inside the loop, which would overwrite the last character
    • Now correctly placed after the loop completion
  • Code style: Removed extra blank lines for consistent formatting (lines 75, 77)
  • License header: Added missing period in Apache License header (line 6)

Test Plan

  • Build completed successfully
  • All Oracle compatibility tests passed (make oracle-check)
  • No regression test failures

Files Changed

  • src/backend/utils/misc/ivy_guc.c: 1 file changed, 14 insertions(+), 17 deletions(-)

🤖 Generated with Claude Code

- Fix typo: "shown as blow" -> "shown below"
- Fix duplicate period in error hint message
- Fix null terminator placement in nls_case_conversion function
- Remove extra blank lines for consistent code style
- Add missing period in Apache License header

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
OreoYang pushed a commit that referenced this pull request Mar 13, 2026
There've been a few complaints that it can be overly difficult to figure
out why the planner picked a Memoize plan.  To help address that, here we
adjust the EXPLAIN output to display the following additional details:

1) The estimated number of cache entries that can be stored at once
2) The estimated number of unique lookup keys that we expect to see
3) The number of lookups we expect
4) The estimated hit ratio

Technically #4 can be calculated using #1, #2 and #3, but it's not a
particularly obvious calculation, so we opt to display it explicitly.
The original patch by Lukas Fittl only displayed the hit ratio, but
there was a fear that might lead to more questions about how that was
calculated.  The idea with displaying all 4 is to be transparent which
may allow queries to be tuned more easily.  For example, if #2 isn't
correct then maybe extended statistics or a manual n_distinct estimate can
be used to help fix poor plan choices.

Author: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
Author: Lukas Fittl <lukas@fittl.com>
Reviewed-by: David Rowley <dgrowleyml@gmail.com>
Reviewed-by: Andrei Lepikhov <lepihov@gmail.com>
Reviewed-by: Robert Haas <robertmhaas@gmail.com>
Discussion: https://postgr.es/m/CAP53Pky29GWAVVk3oBgKBDqhND0BRBN6yTPeguV_qSivFL5N_g%40mail.gmail.com
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.

1 participant