On Tue, Apr 08, 2008 at 07:18:31PM -0400, Tom Lane wrote:
> sure that there's much potential commonality. The thing that's most
> problematic about ecpg is that it wants to offer client-side equivalents
> of some server datatype-manipulation functions; and I don't actually see
> much of any of that in the proposed patch. All that's really here is
> format conversion stuff, so there's no hope of unifying that code
> unless this patch adopts ecpg's choices of client-side representation
ecpg for instance does not use a struct for time, so there doesn't seem
to be an advantance for ecpg in switching. On the other side there's a
disadvantage in that you can binary transfer right now given that you're
on the same architecture. But if the datatypes differ this would be
lost.
> (which I believe are mostly Informix legacy choices, so I'm not sure we
> want that).
Not really. ecpg's pgtypeslib uses the same datatypes as the backend
uses (well, mostly because numeric was changed in the backend after the
creation of pgtypeslib). Then there's a compatibility layer that maps
Informix functions and datatypes to our functions and datatypes.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
