Tom Lane wrote:
> Alvaro Herrera <alvherre@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
