Michael Meskes <meskes@postgresql.org> writes:
>>> As long as both implementations are kept in sync I don't see a reason.
>>
>> Sharing the backend data type converters with client stuff is an obvious
>> win, but its a tedious process probably lacking any motivation. We did
>> look at it though, it is possible.
> I thought we were just talking about some definitions. If we were to
> move the whole logic into one place we might be facing a
> performance penalty inside the backend, maybe not a large one though.
> Others around here are better suited to judge this.
It's already a huge maintenance problem that there are two copies of the
datetime code (and no, they are *not* being kept in sync; most patches
to the core code have not gone into ecpg). The prospect of extending
that mess to even more datatypes fills me with dread.
I don't know what we could do about it though. We can't really
replicate the conveniences of the backend coding environment in a
frontend application, and yet I surely don't want to tighten up the
expectations on backend datatypes to try to make them work in a
frontend-ish environment. The chances of that happening reliably
are about nil.
My feeling is that we should resist the temptation to provide any such
functionality on the frontend side (and yes, that inclues ripping out
ecpg's datetime stuff). It'll be a black hole sucking infinite numbers
of maintenance man-hours, with not nearly enough benefit in return.
regards, tom lane