> I do not think this is a good idea. If the purpose of libpq is not > to abstract away the wire-level protocol, then what is its purpose?
IMHO what currently libpq API does is actually dealing with limited use cases, not abstraction of the protocol. > And how could such a tool avoid breaking libpq, anyway? For one > example, successfully sending any command message normally results in > an internal state change in libpq (so that it knows what to do with > the response). Your proposed API here doesn't cover that. Nor does > it cover actually dealing with the response, which I think would be > needed in most scenarios where you're trying to deal in custom messages. Yes, I did not proposed about the message response handling. That's another story. > If you feel a need to be sending your own messages, I think a locally > hacked fork of libpq is a better answer. I have already done it. I just thought it would be useful to share this if there are someone else who are willing to do the same thing like me. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
