Re: Bug in tm2timestamp
От | Alvaro Herrera |
---|---|
Тема | Re: Bug in tm2timestamp |
Дата | |
Msg-id | 20130304205526.GJ9507@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Bug in tm2timestamp (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Bug in tm2timestamp
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: