Michael Meskes <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers