Обсуждение: Re: [QUESTIONS] ndbm emulation library?

Redircted to 'the proper list' - pgsql-interfaces@postgresql.org

On Fri, 6 Mar 1998, Leslie Mikesell wrote:

> 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?

>
> > 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

On Fri, 6 Mar 1998, Leslie Mikesell wrote:

> >
> > > 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.

    So you basically want to "hide" the SQL commands behind ndbm
compatible function calls?  Have you looked into what is involved?  Do you
want to work on an 'interfaces/ndbm' library? *raised eyebrows*

> > >     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.
>
>     So you basically want to "hide" the SQL commands behind ndbm
> compatible function calls?  Have you looked into what is involved?  Do you
> want to work on an 'interfaces/ndbm' library? *raised eyebrows*

I was hoping someone had already done it.  Other than generalizing
the dbm_open() routine it seems pretty straightforward and it
would take the same amount of work to convert a single app to
use sql directly.

  Les Mikesell
    les@mcs.com