From: | The Hermit Hacker <scrappy(at)hub(dot)org> |
---|---|
To: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
Cc: | "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposed new libpq API |
Date: | 2000-07-06 01:08:25 |
Message-ID: | Pine.BSF.4.21.0007052207120.33627-100000@thelab.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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)?
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Wise | 2000-07-06 01:11:42 | Re: [HACKERS] Re: Revised Copyright: is this more palatable? |
Previous Message | Chris Bitmead | 2000-07-06 00:52:11 | Re: Proposed new libpq API |