Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.org (8.8.8/8.7.5) with ESMTP id MAA26946 for ; Fri, 6 Mar 1998 12:37:44 -0500 (EST) Received: from Mercury.mcs.net (les@Mercury.mcs.net [192.160.127.80]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id LAA07469; Fri, 6 Mar 1998 11:37:40 -0600 (CST) Received: (from les@localhost) by Mercury.mcs.net (8.8.7/8.8.2) id LAA05557; Fri, 6 Mar 1998 11:37:40 -0600 (CST) From: Leslie Mikesell Message-Id: <199803061737.LAA05557@Mercury.mcs.net> Subject: Re: [QUESTIONS] ndbm emulation library? To: scrappy@hub.org (The Hermit Hacker) Date: Fri, 6 Mar 1998 11:37:39 -0600 (CST) Cc: les@Mcs.Net, pgsql-interfaces@postgreSQL.org In-Reply-To: from "The Hermit Hacker" at Mar 6, 98 11:51:58 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text > > > Has anyone done an ndbm emulation library that could be linked into > > existing applications to make them use pgsql tables instead? I guess > > you'd have to use a default hardcoded database name or pick it up > > from the environment but otherwise it seems like it should work and > > be an easy way to get access to the same data via ODBC and all the > > other ways of using pgsql. > > I'm confused, but...why would you want to do this vs using the > standard libpq interface? I've already got apps using ndbm (and getting occasional file corruption). I'd like to fix this and get the benefits of multi-host access and the ability to write new code to access the same data in all the ways possible with pgsql. If we had a wrapper around libpq with ndbm emulation it would be as simple as re-linking my old apps and migrating the data. Les Mikesell les@mcs.com