Обсуждение: 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

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