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
