pgAdmin 8.13 replaces infinite result scrolling with pagination

Moving through a query result is part of interpreting it. The December 12 announcement of pgAdmin 4 version 8.13 replaces infinite scrolling in Query Tool data output with pagination. The project describes the change as an improvement to usability and performance. It gives navigation through the grid an explicit page structure instead of relying on continued scrolling to reveal more output.

This is a change to the administration interface, not to SQL's result semantics. The client displays what a query returns, and its navigation model determines how a person reaches different parts of that output. A result grid can make inspection difficult even when the database returns correct rows. The release addresses that interface alongside several corrections to displayed values and plan details.

I rely on PostgreSQL's EXPLAIN output as the starting point for understanding query plans. A graphical client is useful when its presentation remains faithful to the current query and its values. Pagination belongs to that same concern, because the interface's representation affects what an operator can inspect comfortably and accurately.

Pages make navigation an explicit interface choice

The tagged 8.13 release notes link the pagination change to issue 1780. Pagination replaces an existing interaction, so it affects ordinary Query Tool use rather than requiring adoption of a new database feature. The announcement does not provide a universal page-size recommendation or a measured performance ratio.

Pagination also should not be confused with adding LIMIT and OFFSET to an application's SQL. The announced feature concerns Query Tool data output. The release notice does not establish that navigating a page changes the original query's membership or ordering. Keeping that scope explicit avoids turning a user-interface change into an unsupported claim about server execution.

The distinction matters when investigating a result that appears incomplete. A page is a portion of the client's displayed output, while a SQL restriction determines which rows the database returns. An operator needs to know which boundary they are observing. The new navigation model gives the client a visible structure for traversing output without changing the meaning of the query itself.

The grid also gains alternating row backgrounds and distinct backgrounds for header and serial-number cells. Those changes separate adjacent records and distinguish data from surrounding controls. They complement pagination because navigating output and identifying the current row are related tasks. The release notes also include a correction for row shading that was not retained during scrolling.

Plan details need to follow the current plan

One fix addresses graphical EXPLAIN details that remained open after the plan changed. A detail panel is useful only when its relationship to the current plan is clear. Leaving the previous node's details visible can create an apparent association between old information and a new diagram. The correction concerns the client's presentation, independently of whether PostgreSQL generated the correct plan.

This is a concrete reason to distinguish server output from retained interface state. A new execution plan and a previously opened detail panel can both be valid records in isolation while forming an invalid combined display. The release identifies that transition as a bug. A user inspecting changed SQL should receive details associated with the plan currently being shown.

The debugger receives another representation fix. Function arguments with the character data type could be truncated. That changes the value available for inspection in the debugger, which can affect how a person understands a function call. It is distinct from claiming that PostgreSQL stored a truncated database value. The reported problem belongs to the debugger's handling of the argument.

I consider those presentation fixes substantive administration work. An interface used to diagnose a database must preserve the relationship between displayed information and the operation that produced it. A stale node panel or truncated argument can interfere with that task without any failure in the underlying SQL engine.

Connection and deployment operations change too

The release adds an object-menu option to disconnect all server and database connections. That makes a group connection action available directly in the interface. It is a different operation from terminating arbitrary sessions on the database server, and the announcement describes it in terms of pgAdmin's connections. The wording should preserve that scope.

For containers, the announcement adds support for passing PGADMIN_CONFIG_CONFIG_DATABASE_URI through Docker secrets. The named setting concerns pgAdmin's configuration database. This provides another supported way to supply that deployment value, without implying that all database credentials or every pgAdmin option share the same mechanism.

The editor also gains automatic detection and setting of line endings, including LF and CRLF. That is useful when query text comes from files with different conventions. Other repairs cover an empty geometry crashing Query Tool rendering and an invisible selection cursor in the PSQL tool. Each concerns a specific client behavior that can obstruct inspection or editing.

Version 8.13 therefore changes how results are navigated while repairing several ways the client can misrepresent its current state. The pagination change is the main visible transition. The plan-details correction preserves a more specific invariant, that information shown for a node belongs to the plan currently under inspection.