Merlin Moncure <mmoncure@xxxxxxxxx> writes: > On Mon, Apr 4, 2011 at 9:31 AM, Tom Lane <tgl@xxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
