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: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
