From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug in tm2timestamp |
Date: | 2013-03-04 20:55:26 |
Message-ID: | 20130304205526.GJ9507@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2013-03-04 20:57:32 | Re: Enabling Checksums |
Previous Message | Jim Nasby | 2013-03-04 20:51:55 | Re: Enabling Checksums |