MagicStack / MagicStack/asyncpg
Support for `WHERE` clause when usng `copy_to_table` method
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 8.1k
- フォーク
- 468
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
Hi there!
Since version 12, PostgreSQL has supported a WHERE clause within COPY ... FROM statements:
COPY table_name [ ( column_name [, ...] ) ]
FROM { 'filename' | PROGRAM 'command' | STDIN }
[ [ WITH ] ( option [, ...] ) ]
[ WHERE condition ]
It functions similarly to the WHERE clause used within SELECT statements, subject to some restrictions regarding subqueries.
Recently I've found myself in a situation where I am performing a bulk insert of CSV-formatted data from a remote machine, but would like to skip certain rows - such as those containing null values. From what I can tell, the existing Connection.copy_to_table helper doesn't support this, and I'd need to drop down to private API (the underlying Connection._protocol._copy_in machinery)
I'd appreciate some publicly exposed way of doing this - the simplest approach that comes to mind would be adding a where kwarg to Connection.copy_to_table as well as the Connection._format_copy_opts method. Usage could then look something along the lines of
await conn.copy_to_table("cool_table", source="important_file.csv", where="important_value = 42")
I'm not sure if this is satisfactory, though. There would also need to be some consideration regarding earlier Postgres versions that don't support COPY ... FROM using a WHERE clause.
Please let me know your thoughts - I'm happy to open a PR for implementation if necessary.
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず Connection.copy_to_table と Connection._format_copy_opts を調べ、次にそれらが非公開の Connection._protocol._copy_in の処理にどのようにつながるかを追跡します。PostgreSQL のバージョン互換性がどのように扱われているかを確認し、公開オプションがどのように動作すべきかを決める前に、関連するテストを特定します。COPY ... FROM WHERE 条件を適用するためのサポートされた方法があり、以前の PostgreSQL バージョンに対して適切な動作をすることが完了の条件です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- postgresql, python
- 領域
- databases
- issue の種類
- 機能追加
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100