2016-03-29 20:59 GMT+02:00 Tom Lane <t...@sss.pgh.pa.us>: > 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. >
I have a less courage than you :). The original design worked with almost clients without changes on client side. New design has lot of combinations, that are unknown for old clients. It can be better, because the client authors will do update faster. If PQfformat will returns 0 = text, 1 = traditional binary, 2 = raw text, 3 = raw binary - like you propose, then PQcopyFormat is useless. I see all information just from PQfformat. Regards Pavel > > regards, tom lane >
