Tom Lane wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > Alvaro Herrera wrote: > >> Another point worth considering is that most of this is duplicated by > >> ecpg's libpgtypes. > > > Bah, ignore this. > > Huh? I think you're quite right that it'd be a good idea to get rid of > the duplicated code, if we could. It's always been the backend's free > reliance on palloc and elog/ereport that's been stopping that. I think > we might now have a realistic solution for palloc, but what about elog?
Well, for instance ecpg's EncodeSpecialTimestamp uses a true/false return value instead of raising an error (though its only caller does not check it). There were few uses of elog/ereport that were really problematic, though I admit that even a single one could mean going through a lot of hoops. Simply crafting an implementation of elog/ereport for frontend and ecpg is probably not going to work, though, because ecpg normally returns error codes for the caller to figure out. Maybe we could create a layer on top of ereport, that gets both the error message, sqlstate etc, and also a return code for ECPG. Or a replacement, so instead of ereport() we have, say, cmn_ereport() that expands to errstart/errfinish on backend and something else on ecpg. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
