1: Indexes on all sortable columns are not at all necessary, unless the WHERE clause predicate (not including the cursor predicate) does not hit any indexes, which in my experience is pretty rare. A user looking through their own forum posts, for example, is going to result in a query involving the user ID, and there's almost certainly an index for that.
2: Exposing database keys (either serial primary keys or UUID primary keys) has never been considered a security issue in any source I've ever read. For practical terms for a real web application, the primary key is vital for constructing a form that will update a resource when posted from the client. From outside the application (like, from the wilds of the Internet) the primary key cannot be directly used for any purpose; it's a number or string with no semantic content. Such keys may not even be permanent, as a table in the application database may be updated or migrated in a way that generates new keys for old data. Because including primary keys in a cursor is necessary to disambiguate sort column values that are duplicated between rows (as with city names or people names), the actual value must used and not a hash because the database server does not have access to the hash: the primary key will be added implicitly as the least-significant sort key (after all user-requested or implicit application keys), so an ascending or descending column on a group of sorted-together duplicates is required for the cursor approach to work.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Two things:
1: Indexes on all sortable columns are not at all necessary, unless the WHERE clause predicate (not including the cursor predicate) does not hit any indexes, which in my experience is pretty rare. A user looking through their own forum posts, for example, is going to result in a query involving the user ID, and there's almost certainly an index for that.
2: Exposing database keys (either serial primary keys or UUID primary keys) has never been considered a security issue in any source I've ever read. For practical terms for a real web application, the primary key is vital for constructing a form that will update a resource when posted from the client. From outside the application (like, from the wilds of the Internet) the primary key cannot be directly used for any purpose; it's a number or string with no semantic content. Such keys may not even be permanent, as a table in the application database may be updated or migrated in a way that generates new keys for old data. Because including primary keys in a cursor is necessary to disambiguate sort column values that are duplicated between rows (as with city names or people names), the actual value must used and not a hash because the database server does not have access to the hash: the primary key will be added implicitly as the least-significant sort key (after all user-requested or implicit application keys), so an ascending or descending column on a group of sorted-together duplicates is required for the cursor approach to work.