Re: Exporting more function in libpq

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Exporting more function in libpq
Date: 2016-08-19 13:43:34
Message-ID: 31875.1471614214@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-08-19 13:46:12 Re: Should we cacheline align PGXACT?
Previous Message Yury Zhuravlev 2016-08-19 13:42:05 Re: WIP: About CMake v2