Re: Exporting more function in libpq

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: Exporting more function in libpq
Дата
Msg-id 20160820.023114.1761935188254412785.t-ishii@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: Exporting more function in libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Curing plpgsql's memory leaks for statement-lifespan values
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: errno clobbering in reorderbuffer