Re: Bug in tm2timestamp

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

In response to

Responses

Browse pgsql-hackers by date

  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