COPY không được thiết kế cho việc này. Nó có nghĩa là để xử lý dữ liệu có cấu trúc bảng, vì vậy nó không thể hoạt động nếu không có một số cách phân chia hàng và cột; sẽ luôn có một số ký tự COPY FROM diễn giải như dấu phân cách và COPY TO sẽ chèn một số chuỗi thoát nếu nó tìm thấy một chuỗi trong dữ liệu của bạn. Điều này không tuyệt vời nếu bạn đang tìm kiếm cơ sở I / O tệp chung.
Trên thực tế, các máy chủ cơ sở dữ liệu không được thiết kế cho I / O tệp chung. Đối với một điều, bất cứ điều gì tương tác trực tiếp với hệ thống tệp của máy chủ sẽ yêu cầu vai trò siêu người dùng. Nếu có thể, bạn chỉ nên truy vấn bảng như bình thường và xử lý I / O tệp ở phía máy khách.
Điều đó nói rằng, có một số lựa chọn thay thế:
- Tích hợp sẵn
pg_read_file()vàpg_file_write()từadminpack, cung cấp giao diện trực tiếp nhất cho hệ thống tệp, nhưng cả hai đều bị hạn chế trong thư mục dữ liệu của cụm (và tôi không khuyên bạn nên lưu trữ các tệp ngẫu nhiên do người dùng tạo trong đó). -
lo_import()vàlo_export()là các chức năng tích hợp duy nhất mà tôi biết xử lý trực tiếp với I / O tệp và có quyền truy cập không hạn chế vào hệ thống tệp của máy chủ (trong các ràng buộc do hệ điều hành chủ áp đặt), nhưng giao diện Large Object không đặc biệt thân thiện với người dùng .... - Nếu bạn cài đặt biến thể không đáng tin cậy của ngôn ngữ thủ tục như Perl (
plperlu) hoặc Python (plpythonu), bạn có thể viết các hàm trình bao bọc cho các quy trình I / O bản địa của ngôn ngữ đó. - Không có nhiều thứ bạn không thể hoàn thành thông qua
COPY TO PROGRAMnếu bạn đủ quyết tâm - cho một, bạn có thểCOPY (SELECT 1) TO PROGRAM 'mv <source_file> <target_file>'để khắc phục các hạn chế củapg_file_write()- mặc dù điều này phần nào làm mờ ranh giới giữa SQL và các công cụ bên ngoài (và bất kỳ ai kế thừa cơ sở mã của bạn có thể sẽ không ấn tượng ...).
