On Thu, Jan 8, 2015 at 8:42 PM, Aaron Botsis <aaron@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
