Merlin Moncure <mmoncure@gmail.com> writes:
> On Mon, Apr 4, 2011 at 9:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So really you should be looking at some other DBMS if you want an
>> embedded implementation. It'd be nice if PG could be all things to all
>> people, but it can't; and this is one of the things it can't be.
> That's a perhaps overly strong statement. First of all, we already
> support user provided code (in C no less) in the database. It is raw
> and problematic for most people but it's also pretty cool.
Sure. The difference there is that it's understood by all parties that
user-supplied server-side C code has to conform to the expectations and
coding practices of the server. The server code is in charge, not the
user-supplied code. Generally people who ask for an embedded database
expect the opposite. Certainly people who are accustomed to coding
against the libpq API expect that they are in charge, not libpq. This
is not only a matter of "who calls whom" but who controls memory
management, error recovery practices, etc.
> True embedding where the user application is in direct control of the
> process is of course not practical, but that doesn't mean a tighter
> coupling of user code and the database is not possible. Stored
> procedures (I know I'm way into broken record mode on this) would
> likely cover what Annamalai is looking to do IMSNO, even if they were
> limited to a high level language like plpgsql, since you could still
> dip into C appropriately using classic methods.
Possibly. Annamalai's stated goal of driving a locally-implemented
database through a libpq-ish API, and having that be interchangeable
with a traditional client setup, doesn't seem to fit into this viewpoint
though. I guess to get much further we'd have to ask why is that the
goal and what's the wider purpose?
regards, tom lane