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).
Being designed to be extensible RDBMS, postgres should IMHO also support
multiple protocol modules. I would like one that follows standard
CLI/ODBC/JDBC conventions, also XML-RPC based one would be nice.
We could do it by giving the requested protocol at connection startup
and then talking to that backend module afretwards, or we could have
different protocols listening on different ports.
-----------
Hannu
