## Context
There's an issue with copying / exporting rows from the table editor
with the following conditions:
- Row has a column value that exceeds 10,240 and hence is truncated for
performance reasons
<img width="300" alt="image"
src="https://github.com/user-attachments/assets/4639edbb-ece6-4028-89b6-769ac314c3f3"
/>
- User is trying to copy/export selected rows (not all rows in the
table)
<img width="300" alt="image"
src="https://github.com/user-attachments/assets/e7c0da77-051c-4c46-af0d-f9510e0b37c4"
/>
The copy/export action will return the truncated data which is incorrect
(Should return the full data)
## Problem
This is happening as if we're only copying/exporting selected rows,
we're just using what's been loaded in the table editor to export (as
opposed to if the user is copying/exporting all rows in the table, we'd
be fetching the data from the database first before doing so)
Hence am opting to add a data hydration logic, such that if there's a
selected row that's been truncated, we'd fetch them on demand first
before copying/exporting.
There's limitations to this though - e.g if the table doesn't have a
primary key we can't do this (since we need to run a query to fetch the
data). This is already an existing behaviour when trying to load the
column value in the table editor in the grid so no issues I believe.
We'll just show this toast:
<img width="300" alt="image"
src="https://github.com/user-attachments/assets/442637bb-4b9b-492d-b202-bbf6e5ae7512"
/>
## To test
You'll need a column with a really large value - the way I do it is to
load the data directly into the DB via TablePlus
- [ ] Verify that copying / exporting selected rows with really large
column values copies/exports all the data correctly (there shouldn't be
any truncated value)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Improved handling of truncated cell values during copy and export
operations
* **Bug Fixes**
* Copy and export operations now require an active project selection
* Fixed data export for tables without primary keys
* **Style**
* Updated grid header copy and export control layout
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46268?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Exporting all rows (in CSV, SQL, or JSON format) currently uses offset pagination, which can cause performance problems if the table is large. There is also a correctness problem if the table is being actively updated as the export happens, because the relative row offsets could shift between queries.
Now that composite filters are available in postgres-meta, we can change to using cursor pagination on the primary key (or any non-null unique keys) wherever possible. Where this is not possible, the user will be shown a confirmation dialog explaining the possible performance impact.
---------
Co-authored-by: Ali Waseem <waseema393@gmail.com>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Joshen Lim
