Re: [HACKERS] function question yet again

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

In response to

Responses

Browse pgsql-hackers by date

  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