chore: Add pg_catalog schema prefix to catalog table queries#10004
Open
mzabuawala wants to merge 3 commits into
Open
chore: Add pg_catalog schema prefix to catalog table queries#10004mzabuawala wants to merge 3 commits into
mzabuawala wants to merge 3 commits into
Conversation
WalkthroughThis PR consistently schema-qualifies PostgreSQL system catalog references by replacing unqualified pg_* names with pg_catalog.pg_* across SQL templates, runtime Python queries, tests, fixtures, and LLM report queries. ChangesSystem Catalog Schema Qualification
🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 16
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
web/pgadmin/utils/__init__.py (1)
1001-1011:⚠️ Potential issue | 🟠 Major | ⚡ Quick winSQL injection risk and line-length violation.
Line 1002 has two issues:
SQL injection vulnerability: The f-string directly interpolates
extension_nameinto the SQL query without parameterization. Ifextension_namecomes from untrusted input, this could allow SQL injection attacks.Line-length violation: The line exceeds 79 characters (85 > 79), failing pycodestyle (E501).
🔒 Proposed fix using parameterized query
- sql = f"SELECT * FROM pg_catalog.pg_extension WHERE extname = '{extension_name}'" + sql = ( + "SELECT * FROM pg_catalog.pg_extension " + "WHERE extname = %s" + ) status, res = conn.execute_scalar(sql) + # Update the execute_scalar call to pass extension_name as a parameter: + status, res = conn.execute_scalar(sql, (extension_name,))Note: You may need to adjust the
execute_scalarcall depending on how the connection object handles parameters.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@web/pgadmin/utils/__init__.py` around lines 1001 - 1011, The check_extension_exists function currently builds SQL via an f-string (SQL injection risk and too-long line); change it to use a parameterized query and avoid long lines: construct the SQL as a short string like "SELECT * FROM pg_catalog.pg_extension WHERE extname = %s" (or the param placeholder your conn.execute_scalar expects), call conn.execute_scalar(sql, (extension_name,)) instead of interpolating into the string, and reformat the surrounding lines so no line exceeds 79 chars while preserving the existing status/res return behavior.
🧹 Nitpick comments (1)
web/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/tables/sql/11_plus/get_collation.sql (1)
2-2: ⚡ Quick winInconsistent schema casing within the query.
Line 2 uses lowercase
pg_catalogwhile the rest of the query uses uppercasePG_CATALOG(lines 1, 3, 5). Although PostgreSQL treats unquoted identifiers case-insensitively, consistent casing improves readability.♻️ Proposed fix for consistent casing
- FROM pg_catalog.PG_PARTITIONED_TABLE PARTT + FROM PG_CATALOG.PG_PARTITIONED_TABLE PARTT🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@web/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/tables/sql/11_plus/get_collation.sql` at line 2, Change the inconsistent lowercase schema reference "pg_catalog" to uppercase "PG_CATALOG" in the SQL fragment (the line containing "FROM pg_catalog.PG_PARTITIONED_TABLE PARTT") so it matches the other occurrences of "PG_CATALOG" in the query for consistent casing and readability.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@web/pgadmin/browser/server_groups/servers/databases/dbms_job_scheduler/tests/utils.py`:
- Around line 125-126: The triple-quoted SQL assignment to variable "query" in
tests/utils.py exceeds the 79-character line length; split the long string into
shorter concatenated pieces (either by using implicit string literal
concatenation inside parentheses or by joining two shorter strings) so the
SELECT/IN clause lines are each ≤79 chars, keeping the variable name "query" and
the same SQL content unchanged.
In
`@web/pgadmin/browser/server_groups/servers/databases/event_triggers/tests/utils.py`:
- Line 118: The string literal containing "(select rolname from
pg_catalog.pg_authid where oid " exceeds the 79-char line limit; locate that
literal in
web/pgadmin/browser/server_groups/servers/databases/event_triggers/tests/utils.py
and break it into shorter pieces using implicit string concatenation or split
the SQL into multiple quoted segments (e.g. "(select rolname " + "from
pg_catalog.pg_authid where oid ") or wrap the full string in parentheses and
place a line break so each line is ≤79 chars; ensure the concatenated value
remains the same and run pycodestyle to confirm the E501 is resolved.
In
`@web/pgadmin/browser/server_groups/servers/databases/languages/tests/utils.py`:
- Line 74: The string literal "(select rolname from pg_catalog.pg_authid where
oid " exceeds the 79-char pycodestyle limit; split this long SQL string into
multiple shorter concatenated or implicitly joined string literals (e.g., break
after "pg_catalog.pg_authid" and continue the rest on the next line inside the
same expression) wherever that literal appears (look for the exact substring
"(select rolname from pg_catalog.pg_authid where oid " in the tests/utils.py
file) so each source line stays <=79 chars.
In
`@web/pgadmin/browser/server_groups/servers/databases/schemas/synonyms/tests/utils.py`:
- Around line 73-74: The long SQL invocation in the test helper should be
wrapped to meet the 79-character limit: break the call to pg_cursor.execute(...)
that uses synonym_name into multiple shorter segments (for example split the SQL
string across lines or build the query string on a prior line) so the
pg_cursor.execute call itself stays within 79 chars; keep the same variable
synonym_name and function call pg_cursor.execute to preserve behavior.
In
`@web/pgadmin/browser/server_groups/servers/databases/schemas/tables/columns/tests/utils.py`:
- Around line 196-197: The SQL call pg_cursor.execute("select * from
pg_catalog.pg_attribute where attname='%s'" % col_name) exceeds the line-length
limit; fix by breaking the query string into multiple concatenated or multi-part
strings passed to pg_cursor.execute (e.g., split the literal before the WHERE
clause or use implicit string concatenation) and keep the format operation with
col_name unchanged so the call still reads pg_cursor.execute(<split-string> %
col_name); update only the string literal to span multiple lines to satisfy E501
for the pg_cursor.execute usage.
In
`@web/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/foreign_key/sql/tests/test_foreign_key_properties.py`:
- Around line 35-36: The long SQL string containing "FROM pg_catalog.pg_class
join pg_catalog.pg_attribute on attrelid=pg_class.oid" exceeds 79 chars; split
it into shorter pieces (for example, use implicit concatenation by placing the
parts in parentheses or break into two adjacent string literals like "FROM
pg_catalog.pg_class " "JOIN pg_catalog.pg_attribute ON " "attrelid=pg_class.oid
") so the line length meets pycodestyle (E501) while preserving the exact SQL
text in the code where the JOIN clause string is defined.
In
`@web/pgadmin/browser/server_groups/servers/databases/schemas/tables/tests/test_column_acl_sql.py`:
- Around line 31-32: The long SQL string in test_column_acl_sql.py that contains
"FROM pg_catalog.pg_class JOIN pg_catalog.pg_attribute ON attrelid=pg_class.oid"
exceeds the line-length limit; split that SQL literal into smaller string
fragments (use implicit concatenation inside parentheses or separate
+-concatenated literals) so each line stays under the E501 limit, keeping the
SQL tokens intact and preserving whitespace between fragments.
In
`@web/pgadmin/browser/server_groups/servers/databases/schemas/tables/tests/test_trigger_get_oid_sql.py`:
- Around line 31-32: The SQL string fragment in test_trigger_get_oid_sql.py
("FROM pg_catalog.pg_class JOIN pg_catalog.pg_attribute ON "
"attrelid=pg_class.oid ") exceeds the line-length limit; fix it by breaking the
long string into shorter concatenated pieces (e.g., split after a logical
boundary like "JOIN" or "ON") or use implicit concatenation inside parentheses
so each source line stays under the E501 limit while preserving the exact SQL
content referenced in the test.
In
`@web/pgadmin/browser/server_groups/servers/databases/schemas/tables/tests/utils.py`:
- Around line 613-614: The pg_cursor.execute call with the long SQL string
(pg_cursor.execute("SELECT COUNT(*) FROM pg_catalog.pg_available_extensions
WHERE name ='postgis'")) exceeds the max line length; break the SQL into shorter
literal pieces (e.g. use implicit string joining with adjacent quoted strings or
concatenate two shorter strings) or format it as a multi-line parenthesized
string so the call to pg_cursor.execute remains within line length limits while
keeping the same SQL text.
In `@web/pgadmin/dashboard/__init__.py`:
- Line 701: The SQL assignment to the variable sql currently exceeds the
79-character limit; update the assignment in web/pgadmin/dashboard/__init__.py
so the string is split across multiple lines (use implicit string literal
concatenation in parentheses, a triple-quoted string, or join parts) without
changing the SQL content; locate the sql variable assignment and reformat it
into two or more shorter string pieces (e.g., "SELECT * FROM pg_catalog." +
"pg_extension WHERE extname = 'system_stats';" or use a parenthesized multi-line
string) to satisfy pycodestyle E501.
In `@web/pgadmin/llm/__init__.py`:
- Line 1462: The SQL query string assignments at the schema_query variable and
three other similar query assignments exceed the 79-character line-length limit
set by pycodestyle (E501). Split each of these four long query strings across
multiple lines using implicit string concatenation or continuation to ensure
each line stays within the 79-character limit. Apply this refactoring
consistently at all four locations mentioned (lines 1462, 1541, 1994, and 2073).
In `@web/pgadmin/llm/reports/queries.py`:
- Line 408: The long SQL fragments (e.g. "(SELECT count(*) FROM
pg_catalog.pg_stat_activity) as total_connections," and the other long SELECT
fragment at line 508) exceed the 79-character limit; fix by breaking those long
lines into multiple shorter string pieces or use implicit Python string
concatenation inside parentheses so each physical line is <=79 chars, preserving
the same SQL content and trailing commas/spacing; update the SQL expression(s)
in web/pgadmin/llm/reports/queries.py where these fragments appear to split the
long literal into two or more lines (or join with "+" if needed) without
changing identifiers or alias names.
In `@web/pgadmin/utils/driver/psycopg3/connection.py`:
- Around line 519-521: The inline comment in connection.py (the comment starting
"Note that we use 'UPDATE pg_catalog.pg_settings'...") exceeds the 79-character
line-length rule; split/reflow that comment across multiple shorter lines (<=79
chars) preserving the original wording and meaning, for example breaking after
phrases like "for setting bytea_output as a" and "convenience hack for those
running on old, unsupported versions of PostgreSQL" so each resulting comment
line is within the pycodestyle limit; update the comment near the existing block
in psycopg3 connection.py accordingly.
- Around line 450-451: The SQL assignment to _query in connection.py exceeds the
79-char line limit; update the _query construction in the method where _query is
defined so the SQL literal is split across multiple shorter string segments
(e.g., use implicit string concatenation inside parentheses or split into two
quoted pieces) while still calling self.qtLiteral(role, self.conn) to
interpolate the role value; ensure the resulting _query variable content is
identical but no single source line exceeds 79 characters.
In `@web/regression/python_test_utils/test_utils.py`:
- Around line 1910-1911: The SQL query in check_extension_exists currently
interpolates extension_name into the SQL string (cursor.execute(f"""SELECT
COUNT(*) FROM pg_catalog.pg_extension WHERE extname='{extension_name}'""")),
which risks quoting/SQL issues; change the call to use parameterized execution
instead by passing a query with a placeholder (e.g., WHERE extname = %s) and
supply (extension_name,) as the parameters argument to cursor.execute so the DB
driver handles quoting safely.
In `@web/regression/re_sql/tests/test_resql.py`:
- Around line 851-856: Replace the string-interpolated SQL calls that use
db_name with parameterized queries to avoid SQL injection and long-line issues:
change the two pg_cursor.execute(...) calls that build "SELECT datcollate ...
WHERE datname = '{0}'".format(db_name) and "SELECT datctype ... WHERE datname =
'{0}'".format(db_name) to use bind parameters (e.g. pg_cursor.execute("SELECT
datcollate as cname FROM pg_catalog.pg_database WHERE datname = %s", (db_name,))
and similarly for datctype) and then fetch into lc_collate as before; also break
long lines if needed to satisfy line-length checks.
---
Outside diff comments:
In `@web/pgadmin/utils/__init__.py`:
- Around line 1001-1011: The check_extension_exists function currently builds
SQL via an f-string (SQL injection risk and too-long line); change it to use a
parameterized query and avoid long lines: construct the SQL as a short string
like "SELECT * FROM pg_catalog.pg_extension WHERE extname = %s" (or the param
placeholder your conn.execute_scalar expects), call conn.execute_scalar(sql,
(extension_name,)) instead of interpolating into the string, and reformat the
surrounding lines so no line exceeds 79 chars while preserving the existing
status/res return behavior.
---
Nitpick comments:
In
`@web/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/tables/sql/11_plus/get_collation.sql`:
- Line 2: Change the inconsistent lowercase schema reference "pg_catalog" to
uppercase "PG_CATALOG" in the SQL fragment (the line containing "FROM
pg_catalog.PG_PARTITIONED_TABLE PARTT") so it matches the other occurrences of
"PG_CATALOG" in the query for consistent casing and readability.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 962715c0-a5b1-4a58-87b5-27a6cdbe4d66
📒 Files selected for processing (77)
web/pgadmin/browser/server_groups/servers/databases/dbms_job_scheduler/__init__.pyweb/pgadmin/browser/server_groups/servers/databases/dbms_job_scheduler/tests/utils.pyweb/pgadmin/browser/server_groups/servers/databases/event_triggers/tests/utils.pyweb/pgadmin/browser/server_groups/servers/databases/foreign_data_wrappers/foreign_servers/templates/foreign_servers/sql/default/delete.sqlweb/pgadmin/browser/server_groups/servers/databases/languages/tests/utils.pyweb/pgadmin/browser/server_groups/servers/databases/publications/templates/publications/pg/15_plus/sql/get_tables.sqlweb/pgadmin/browser/server_groups/servers/databases/publications/templates/publications/pg/default/sql/get_all_columns.sqlweb/pgadmin/browser/server_groups/servers/databases/publications/templates/publications/pg/default/sql/get_tables.sqlweb/pgadmin/browser/server_groups/servers/databases/publications/templates/publications/ppas/15_plus/sql/get_tables.sqlweb/pgadmin/browser/server_groups/servers/databases/publications/templates/publications/ppas/default/sql/get_all_columns.sqlweb/pgadmin/browser/server_groups/servers/databases/publications/templates/publications/ppas/default/sql/get_tables.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/aggregates/templates/aggregates/sql/11_plus/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/aggregates/templates/aggregates/sql/default/nodes.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/aggregates/templates/aggregates/sql/default/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/foreign_table_columns/tests/utils.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/functions/templates/functions/pg/sql/13_plus/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/functions/templates/functions/pg/sql/14_plus/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/functions/templates/functions/ppas/sql/13_plus/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/functions/templates/functions/ppas/sql/14_plus/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/functions/templates/procedures/pg/sql/13_plus/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/functions/templates/procedures/pg/sql/14_plus/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/functions/templates/procedures/ppas/sql/13_plus/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/functions/templates/procedures/ppas/sql/14_plus/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/synonyms/tests/utils.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/columns/tests/utils.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/foreign_key/sql/tests/test_foreign_key_properties.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/indexes/sql/11_plus/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/indexes/sql/13_plus/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/indexes/sql/15_plus/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/indexes/sql/default/nodes.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/indexes/sql/default/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/tables/sql/11_plus/get_collation.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/tables/sql/12_plus/get_tables_for_constraints.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/tables/sql/default/get_tables_for_constraints.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/tests/test_column_acl_sql.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/tests/test_trigger_get_oid_sql.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/tests/utils.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/types/__init__.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/types/templates/types/pg/sql/14_plus/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/types/templates/types/pg/sql/default/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/types/templates/types/ppas/sql/14_plus/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/types/templates/types/ppas/sql/default/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/views/templates/mviews/pg/13_plus/sql/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/views/templates/mviews/pg/15_plus/sql/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/views/templates/mviews/ppas/13_plus/sql/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/views/templates/mviews/ppas/15_plus/sql/properties.sqlweb/pgadmin/browser/server_groups/servers/databases/schemas/views/tests/view_test_data.jsonweb/pgadmin/browser/server_groups/servers/databases/subscriptions/templates/subscriptions/sql/default/stats.sqlweb/pgadmin/browser/server_groups/servers/databases/templates/databases/sql/15_plus/get_icu_locale.sqlweb/pgadmin/browser/server_groups/servers/databases/templates/databases/sql/16_plus/get_ctypes.sqlweb/pgadmin/browser/server_groups/servers/databases/templates/databases/sql/17_plus/get_builtin_locale.sqlweb/pgadmin/browser/server_groups/servers/databases/templates/databases/sql/17_plus/get_ctypes.sqlweb/pgadmin/browser/server_groups/servers/databases/templates/databases/sql/17_plus/get_icu_locale.sqlweb/pgadmin/browser/server_groups/servers/directories/tests/utils.pyweb/pgadmin/browser/server_groups/servers/replica_nodes/templates/replica_nodes/sql/default/count.sqlweb/pgadmin/browser/server_groups/servers/replica_nodes/templates/replica_nodes/sql/default/nodes.sqlweb/pgadmin/browser/server_groups/servers/replica_nodes/templates/replica_nodes/sql/default/properties.sqlweb/pgadmin/browser/server_groups/servers/roles/templates/roles/sql/default/properties.sqlweb/pgadmin/browser/server_groups/servers/templates/servers/sql/default/replication_type.sqlweb/pgadmin/browser/server_groups/servers/tests/servers_test_data.jsonweb/pgadmin/dashboard/__init__.pyweb/pgadmin/dashboard/templates/dashboard/sql/default/replication_slots.sqlweb/pgadmin/dashboard/templates/dashboard/sql/default/replication_stats.sqlweb/pgadmin/llm/__init__.pyweb/pgadmin/llm/reports/generator.pyweb/pgadmin/llm/reports/queries.pyweb/pgadmin/tools/schema_diff/tests/pg/12_plus/source.sqlweb/pgadmin/tools/schema_diff/tests/pg/17_plus/source.sqlweb/pgadmin/tools/search_objects/templates/search_objects/sql/pg/11_plus/search.sqlweb/pgadmin/tools/search_objects/templates/search_objects/sql/pg/default/search.sqlweb/pgadmin/tools/search_objects/templates/search_objects/sql/ppas/11_plus/search.sqlweb/pgadmin/tools/search_objects/templates/search_objects/sql/ppas/12_plus/search.sqlweb/pgadmin/tools/search_objects/templates/search_objects/sql/ppas/default/search.sqlweb/pgadmin/utils/__init__.pyweb/pgadmin/utils/driver/psycopg3/connection.pyweb/regression/python_test_utils/test_utils.pyweb/regression/re_sql/tests/test_resql.py
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
web/pgadmin/utils/driver/psycopg3/connection.py (2)
450-452:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix line-length violation.
Line 450 exceeds the 79-character limit (84 characters). Break the SQL string across multiple lines to comply with pycodestyle (E501).
🔧 Proposed fix to split the SQL string
- _query = "SELECT rolname from pg_catalog.pg_roles " \ - "WHERE rolname = {0}" \ - "".format(self.qtLiteral(role, self.conn)) + _query = ( + "SELECT rolname FROM pg_catalog.pg_roles " + "WHERE rolname = {0}" + ).format(self.qtLiteral(role, self.conn))🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@web/pgadmin/utils/driver/psycopg3/connection.py` around lines 450 - 452, The SQL assignment to _query in connection.py exceeds the 79-char limit; split the SQL string into multiple shorter parts (using implicit string literal concatenation or enclosing the full string in parentheses) so no line is longer than 79 chars, preserving the call to self.qtLiteral(role, self.conn) and the overall format: "_query = ... .format(self.qtLiteral(role, self.conn))"; update only the string literal splitting around "SELECT rolname from pg_catalog.pg_roles" and the WHERE clause so pycodestyle E501 is satisfied while keeping the same SQL content and .format call.
520-523:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix line-length violation in comment.
Line 519 (preceding the visible change) exceeds the 79-character limit (88 characters). Reflow the comment across multiple lines to comply with pycodestyle (E501).
🔧 Proposed fix to reflow the comment
- # Note that we use 'UPDATE pg_catalog.pg_settings' for setting bytea_output as a - # convenience hack for those running on old, unsupported versions of - # PostgreSQL 'cos we're nice like that. + # Note that we use 'UPDATE pg_catalog.pg_settings' for setting + # bytea_output as a convenience hack for those running on old, + # unsupported versions of PostgreSQL 'cos we're nice like that.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@web/pgadmin/utils/driver/psycopg3/connection.py` around lines 520 - 523, The long comment explaining the use of "UPDATE pg_catalog.pg_settings" to set bytea_output exceeds 79 chars; reflow it into multiple shorter lines (each ≤79 chars) while preserving the original wording and meaning, e.g. break the sentence after logical phrases so the lines stay within the pycodestyle limit; update the comment block that mentions "UPDATE pg_catalog.pg_settings" and "bytea_output" accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@web/pgadmin/browser/server_groups/servers/databases/schemas/synonyms/tests/utils.py`:
- Around line 73-75: verify_synonym and create_synonym currently build SQL with
Python % string interpolation which risks SQL injection; change the value-based
WHERE clauses (e.g., "WHERE synname='%s'") to use parameterized execution (pass
synonym_name as a query parameter to pg_cursor.execute instead of formatting
into the string), and for SQL that embeds identifiers (CREATE OR REPLACE SYNONYM
%s.%s FOR %s.%s and the SELECT s.oid ... WHERE s.synname='%s' in create_synonym)
switch to psycopg.sql composition using psycopg.sql.Identifier and
psycopg.sql.SQL to safely quote schema/table/synonym identifiers (construct the
SQL with SQL() and Identifier() and pass parameters where appropriate) so no
user values are interpolated directly into the query string.
In `@web/pgadmin/utils/__init__.py`:
- Around line 1002-1005: The SQL currently interpolates extension_name directly
into the string (variable sql) causing SQL injection; change to a parameterized
query and pass extension_name via the conn.execute_scalar params argument
instead of f-string interpolation (e.g. use "SELECT * FROM
pg_catalog.pg_extension WHERE extname = %s" and call conn.execute_scalar with
the SQL and the extension_name parameter). Ensure you update the code paths that
call conn.execute_scalar so they pass the parameter rather than using the
f-string.
---
Duplicate comments:
In `@web/pgadmin/utils/driver/psycopg3/connection.py`:
- Around line 450-452: The SQL assignment to _query in connection.py exceeds the
79-char limit; split the SQL string into multiple shorter parts (using implicit
string literal concatenation or enclosing the full string in parentheses) so no
line is longer than 79 chars, preserving the call to self.qtLiteral(role,
self.conn) and the overall format: "_query = ... .format(self.qtLiteral(role,
self.conn))"; update only the string literal splitting around "SELECT rolname
from pg_catalog.pg_roles" and the WHERE clause so pycodestyle E501 is satisfied
while keeping the same SQL content and .format call.
- Around line 520-523: The long comment explaining the use of "UPDATE
pg_catalog.pg_settings" to set bytea_output exceeds 79 chars; reflow it into
multiple shorter lines (each ≤79 chars) while preserving the original wording
and meaning, e.g. break the sentence after logical phrases so the lines stay
within the pycodestyle limit; update the comment block that mentions "UPDATE
pg_catalog.pg_settings" and "bytea_output" accordingly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: fdaa05c4-a4a3-4599-becc-40fe246e973b
📒 Files selected for processing (16)
web/pgadmin/browser/server_groups/servers/databases/dbms_job_scheduler/tests/utils.pyweb/pgadmin/browser/server_groups/servers/databases/event_triggers/tests/utils.pyweb/pgadmin/browser/server_groups/servers/databases/languages/tests/utils.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/foreign_table_columns/tests/utils.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/synonyms/tests/utils.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/columns/tests/utils.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/foreign_key/sql/tests/test_foreign_key_properties.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/tests/test_column_acl_sql.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/tests/test_trigger_get_oid_sql.pyweb/pgadmin/browser/server_groups/servers/databases/schemas/tables/tests/utils.pyweb/pgadmin/dashboard/__init__.pyweb/pgadmin/llm/__init__.pyweb/pgadmin/llm/reports/queries.pyweb/pgadmin/utils/__init__.pyweb/pgadmin/utils/driver/psycopg3/connection.pyweb/regression/re_sql/tests/test_resql.py
✅ Files skipped from review due to trivial changes (2)
- web/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/foreign_key/sql/tests/test_foreign_key_properties.py
- web/pgadmin/browser/server_groups/servers/databases/schemas/tables/tests/test_trigger_get_oid_sql.py
🚧 Files skipped from review as they are similar to previous changes (8)
- web/pgadmin/browser/server_groups/servers/databases/schemas/tables/tests/test_column_acl_sql.py
- web/pgadmin/browser/server_groups/servers/databases/languages/tests/utils.py
- web/pgadmin/browser/server_groups/servers/databases/dbms_job_scheduler/tests/utils.py
- web/pgadmin/browser/server_groups/servers/databases/schemas/tables/tests/utils.py
- web/pgadmin/dashboard/init.py
- web/pgadmin/browser/server_groups/servers/databases/event_triggers/tests/utils.py
- web/pgadmin/llm/reports/queries.py
- web/pgadmin/llm/init.py
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
Bug Fixes
Refactor