On Thu, Jan 8, 2015 at 8:42 PM, Aaron Botsis <aa...@bt-r.com> wrote: > This version: > > * doesn't allow ENCODING in BINARY mode (existing bug) > * doesn’t allow ESCAPE in BINARY mode
Hmm, it does look like ENCODING and ESCAPE don't do anything in BINARY mode, so adding error checks for that makes sense to me. I wondered whether the ENCODING option would affect the interpretation of text data that might be stored in binary-format COPY data, but I can't find any evidence that it does. > * makes COPY TO work with escape I don't see anything horribly wrong with this, but it seems pretty useless. I mean, does anyone really want a newline encoded in the output as %n or !n or qn rather than \n? What problem are you trying to solve here? > * ensures escape char length is < 2 for text mode, 1 for CSV So, is the idea here that we're going to have no escape character at all? So, the characters that would require the use of an escape character to represent simply can't be represented at all, but we're OK with that, because the input data doesn't contain any such characters? One general problem with this patch is that it doesn't update the documentation, which makes it a bit harder than it might be to see what you're trying to accomplish. Also, if you want to decrease the chances that this patch will get forgotten about, you can register it here: https://commitfest.postgresql.org/action/commitfest_view/open -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
