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: | Raw Message | Whole Thread | 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 |