From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Exporting more function in libpq |
Date: | 2016-08-19 17:31:14 |
Message-ID: | 20160820.023114.1761935188254412785.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-08-19 17:41:36 | Re: errno clobbering in reorderbuffer |
Previous Message | Jim Nasby | 2016-08-19 17:29:09 | Re: Curing plpgsql's memory leaks for statement-lifespan values |