Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
On Thu, Oct 06, 2005 at 10:38:54PM -0400, Bruce Momjian wrote:
I don't know if people want this for 8.1 or 8.2.
8.1, IMHO. It's a bug fix. :)
Not unless Joe Conway signs off on it ...
I had asked on the original simple patch, a
Joe Conway wrote:
> Tom Lane wrote:
> > David Fetter <[EMAIL PROTECTED]> writes:
> >
> >>On Thu, Oct 06, 2005 at 10:38:54PM -0400, Bruce Momjian wrote:
> >>
> >>>I don't know if people want this for 8.1 or 8.2.
> >
> >>8.1, IMHO. It's a bug fix. :)
> >
> > Not unless Joe Conway signs off on it
Bruce Momjian writes:
> Well, as I said in the patch email:
> The reported problem is that dblink_open/dblink_close() (for cursor
> reads) do a BEGIN/COMMIT regardless of the transaction state of the
> remote connection. There was code in dblink.c to track the remote
> tr
Tom Lane wrote:
> Bruce Momjian writes:
> > Well, as I said in the patch email:
>
> > The reported problem is that dblink_open/dblink_close() (for cursor
> > reads) do a BEGIN/COMMIT regardless of the transaction state of the
> > remote connection. There was code in dblink.c to track
Bruce Momjian writes:
> The problem with not using rconn is that we are not saving the
> transaction status at the _start_ of the cursor open. If we don't do
> that, we have no way of knowing on close if _we_ opened the transaction
> or whether it was opened by the user.
Oh, I see. In that case
Tom Lane wrote:
> Bruce Momjian writes:
> > The problem with not using rconn is that we are not saving the
> > transaction status at the _start_ of the cursor open. If we don't do
> > that, we have no way of knowing on close if _we_ opened the transaction
> > or whether it was opened by the user.
Tom Lane wrote:
> Bruce Momjian writes:
> > Right. We allow leap seconds for any date/time. Are you saying we
> > should only allow them for certain dates/times?
>
> No, his point is the funny roundoff behavior.
>
> regression=# select timestamp '2005-09-23 23:59:59.99';
> timesta
Bruce Momjian writes:
> I have gone through the code and identified all the places that need
> JROUND, basically places where we do complex calculations that include
> fsec (fractional seconds). This only affects timestamp=double backends,
> not timestamp=int64.
I'm not sure I like this approach
Tom Lane wrote:
> Bruce Momjian writes:
> > I have gone through the code and identified all the places that need
> > JROUND, basically places where we do complex calculations that include
> > fsec (fractional seconds). This only affects timestamp=double backends,
> > not timestamp=int64.
>
> I'm
Bruce Momjian writes:
> Tom Lane wrote:
>> I think it'd probably be better to just fix the rounding during display.
> If we do that, should we remove some the existing JROUND calls in the
> code? I think we have to do this consistently, at least.
Yeah, I was looking at that --- I think most if
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I think it'd probably be better to just fix the rounding during display.
>
> > If we do that, should we remove some the existing JROUND calls in the
> > code? I think we have to do this consistently, at least.
>
> Yeah, I was look
11 matches
Mail list logo
