| From: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
|---|---|
| To: | "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proposed new libpq API |
| Date: | 2000-07-06 00:52:11 |
| Message-ID: | 3963D83B.E081E89A@nimrod.itg.telecom.com.au |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"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).
| From | Date | Subject | |
|---|---|---|---|
| Next Message | The Hermit Hacker | 2000-07-06 01:08:25 | Re: Proposed new libpq API |
| Previous Message | Mike Mascari | 2000-07-06 00:44:02 | Re: update on TOAST status |