Re: [HACKERS] function question yet again
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] function question yet again |
Дата | |
Msg-id | 24028.950650165@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] function question yet again (Mike Mascari <mascarm@mascari.com>) |
Ответы |
Re: [HACKERS] function question yet again
|
Список | pgsql-hackers |
Mike Mascari <mascarm@mascari.com> writes: > Wow. I'm not quite sure why it shouldn't work, but I've never > reconnected on the server side through libpq. Instead, I've > always used the SPI interface sequence of: > SPI_connect() > SPI_exec() > SPI_getvalue() > SPI_finish() SPI is the recommended interface for server-side addon code, I think. > I think I've tried in the past to reconnect on the server side > through libpq but it always resulted in a core dump of the > running backend. Bear in mind that libpq is not present in the backend. If you load a library containing your code + libpq and then try to do something via libpq, what will happen is that libpq will contact the postmaster, fire up a new backend, and send all your queries to that other backend. Probably not quite what you had in mind, and I could imagine it leading to deadlock problems against your own backend. (But I don't see why it would cause the particular error Michael is complaining of; that still looks like it might be a newline-versus-carriage-return kind of bug.) I believe that long ago, there was code in the backend that presented a libpq-equivalent interface for queries originating from loaded libraries, but that facility hasn't been maintained and probably doesn't work at all anymore. regards, tom lane
В списке pgsql-hackers по дате отправления: