Thread: Exporting more function in libpq
I would like to proppse to export these functions in libpq. pqPutMsgStart pqPutMsgEnd pqPutc pqPuts pqPutInt pqPutnchar pqFlush pqHandleSendFailure I think this would be useful to create a tool/library which needs to handle frontend/backend protocol messages in detail. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Tatsuo Ishii <ishii@sraoss.co.jp> writes:
> I would like to proppse to export these functions in libpq.
> pqPutMsgStart
> pqPutMsgEnd
> pqPutc
> pqPuts
> pqPutInt
> pqPutnchar
> pqFlush
> pqHandleSendFailure
> I think this would be useful to create a tool/library which needs to
> handle frontend/backend protocol messages in detail.
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?
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.
If you feel a need to be sending your own messages, I think a locally
hacked fork of libpq is a better answer.
regards, tom lane
> 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
On 19 August 2016 at 14:17, Tatsuo Ishii <ishii@sraoss.co.jp> wrote:
I would like to proppse to export these functions in libpq.
pqPutMsgStart
pqPutMsgEnd
pqPutc
pqPuts
pqPutInt
pqPutnchar
pqFlush
pqHandleSendFailure
I think this would be useful to create a tool/library which needs to
handle frontend/backend protocol messages in detail.
Shouldn't that generally be done by extending libpq to add the required functionality?
If you're extending the server-side protocol and want to handle new message types, you're presumably able to extend libpq too. If you're not extending the server-side protocol, what is it that you want to do but cannot currently do with libpq? Is there a reaonable way to add that to libpq?
Craig Ringer wrote: > On 19 August 2016 at 14:17, Tatsuo Ishii <ishii@sraoss.co.jp> wrote: > > > I would like to proppse to export these functions in libpq. > > > > pqPutMsgStart > > pqPutMsgEnd > > pqPutc > > pqPuts > > pqPutInt > > pqPutnchar > > pqFlush > > pqHandleSendFailure > > > > I think this would be useful to create a tool/library which needs to > > handle frontend/backend protocol messages in detail. > > Shouldn't that generally be done by extending libpq to add the required > functionality? The thought that came to me was that maybe we need a separate library that handles the lower level operations (a "fe/be" library, if you will) which can be exported for others to use and is used by libpq to implement the slightly-higher-level functionality. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Craig Ringer wrote:
>> Shouldn't that generally be done by extending libpq to add the required
>> functionality?
> The thought that came to me was that maybe we need a separate library
> that handles the lower level operations (a "fe/be" library, if you will)
> which can be exported for others to use and is used by libpq to
> implement the slightly-higher-level functionality.
If you wanted a library that exposed something close to the wire-level
protocol, I do not think that tearing out some of the oldest and cruftiest
parts of libpq and exposing them verbatim is really the best way to go
about it.
regards, tom lane