From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mike Mascari <mascarm(at)mascari(dot)com> |
Cc: | Michael Meskes <meskes(at)postgreSQL(dot)org>, PostgreSQL Hacker <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] function question yet again |
Date: | 2000-02-15 21:29:25 |
Message-ID: | 24028.950650165@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mike Mascari <mascarm(at)mascari(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Lamar Owen | 2000-02-15 21:37:25 | Re: [HACKERS] Interbase |
Previous Message | Bruce Momjian | 2000-02-15 21:18:31 | Re: [HACKERS] Most Advanced |