Pavel Stehule <pavel.steh...@gmail.com> writes: > I am writing few lines as summary:
> 1. invention RAW_TEXT and RAW_BINARY > 2. for RAW_BINARY: PQbinaryTuples() returns 1 and PQfformat() returns 1 > 3.a for RAW_TEXT: PQbinaryTuples() returns 0 and PQfformat() returns 0, but > the client should to check PQcopyFormat() to not print "\n" on the end > 3.b for RAW_TEXT: PQbinaryTuples() returns 1 and PQfformat() returns 1, but > used output function, not necessary client modification > 4. PQcopyFormat() returns 0 for text, 1 for binary, 2 for RAW_TEXT, 3 for > RAW_BINARY > 5. create tests for ecpg 3.b certainly seems completely wrong. PQfformat==1 would imply binary data. I suggest that PQcopyFormat should be understood as defining the format of the copy data encapsulation, not the individual fields. So it would go like 0 = traditional text format, 1 = traditional binary format, 2 = raw (no encapsulation). You'd need to also look at PQfformat to distinguish raw text from raw binary. But if we do it as you suggest above, we've locked ourselves into only ever having two field format codes, which is something the existing design is specifically intended to allow expansion in. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers