Michael Meskes wrote:
> On Mon, Mar 04, 2013 at 05:08:26PM -0300, Alvaro Herrera wrote:
> > Another point worth considering is that most of this is duplicated by
> > ecpg's libpgtypes. Do we want to fix that one too, or do we just let it
> > continue to be broken? I note that other bugs are alrea
On Mon, Mar 04, 2013 at 05:55:26PM -0300, Alvaro Herrera wrote:
> 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
> ...
Couldn't we just create ecpg's own version of ereport, that does "the right
thing
On Mon, Mar 04, 2013 at 05:08:26PM -0300, Alvaro Herrera wrote:
> Another point worth considering is that most of this is duplicated by
> ecpg's libpgtypes. Do we want to fix that one too, or do we just let it
> continue to be broken? I note that other bugs are already unfixed in
> ecpg's copy.
Tom Lane wrote:
> Alvaro Herrera 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 c
On Mon, Mar 4, 2013 at 8:54 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> AFAICT, there's a bug in tm2timestamp(). You can't do this:
>> postgres=# select '1999-12-31T24:00:00'::timestamptz;
>> ERROR: timestamp out of range: "1999-12-31T24:00:00"
>
>> But that's a perfectly legal date. It wor
Alvaro Herrera 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 backen
Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > BTW, it strikes me that it's a bit silly to go to all this effort
> > here, and then ignore the possibility of overflow in the dt2local
> > adjustment just below. But we'd have to change the API of that
> > function, which I don't especially feel like
Tom Lane wrote:
> BTW, it strikes me that it's a bit silly to go to all this effort
> here, and then ignore the possibility of overflow in the dt2local
> adjustment just below. But we'd have to change the API of that
> function, which I don't especially feel like doing right now.
Another point w
Magnus Hagander writes:
> AFAICT, there's a bug in tm2timestamp(). You can't do this:
> postgres=# select '1999-12-31T24:00:00'::timestamptz;
> ERROR: timestamp out of range: "1999-12-31T24:00:00"
> But that's a perfectly legal date. It works fine for any other year -
> and AFAICT this is becaus
AFAICT, there's a bug in tm2timestamp(). You can't do this:
postgres=# select '1999-12-31T24:00:00'::timestamptz;
ERROR: timestamp out of range: "1999-12-31T24:00:00"
But that's a perfectly legal date. It works fine for any other year -
and AFAICT this is because of the POSTGRES_EPOCH_JDATE bein
10 matches
Mail list logo
