On Thu, 6 Jul 2000, Chris Bitmead wrote:
> "Timothy H. Keitt" wrote:
> >
> > If I were implementing this in C++, I would have the result object
> > return a different generic STL iterator (forward, random access, etc.)
> > depending on how I wanted to access the data. Perhaps you could emulate
> > this in C. I generally don't like the one-interface-fits-all approach;
> > you get a much cleaner and extensible interface if you introduce a type
> > for each class of behavior being modeled.
>
> If we want to relagate the current API to the status of "legacy", and
> build something all-new and well thought out, then this could be done.
> I'd certainly be willing to do this, but what is the consensus? If I
> came up with something completely different but better would the rest of
> the team be happy to make the current interface legacy? Or do we want a
> compromise (like what Peter Eisentraut suggests perhaps), or do we want
> something that slots into the current world view with minimum
> disruption? (what I have suggested).
Could we create some sort of libpq2? Maintain libpq for a release or two
and then slow fade it out? Or maybe have a configure switch
(--enable-libpq-compat)?
