Brendan Jurd wrote:
On Sat, Nov 1, 2008 at 3:42 PM, Ron Mayer [EMAIL PROTECTED] wrote:
# Patch 3: cleanup.patch
Fix rounding inconsistencies and refactor interval input/output code
Compile, testing and regression tests all checked out.
I've picked up on a few code style issues, fixes
On Wed, Nov 12, 2008 at 5:32 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
* AdjustFractionalSeconds = AdjustFractSeconds
* AdjustFractionalDays = AdjustFractDays
Otherwise many lines were over 80 chars long.
And it happened often enough I thought the shorter name
was less
Brendan Jurd wrote:
On Wed, Nov 12, 2008 at 5:32 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
* AdjustFractionalSeconds = AdjustFractSeconds
* AdjustFractionalDays = AdjustFractDays
Otherwise many lines were over 80 chars long.
And it happened often enough I thought the
On Wed, Nov 12, 2008 at 6:13 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
I don't have any further gripes regarding this patch, apart from the
code style stuff I sent through in my previous post. Did you have any
response to those?
Yup - you were right again.
Applied them and
Brendan Jurd [EMAIL PROTECTED] writes:
On Wed, Nov 12, 2008 at 5:32 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
There are some very large-scale changes to the regression tests. ...
Previously, much (but IIRC not quite all) of the interval output stuff
rounded to the
Ron Mayer [EMAIL PROTECTED] writes:
Brendan Jurd wrote:
I don't have any further gripes regarding this patch, apart from the
code style stuff I sent through in my previous post. Did you have any
response to those?
Yup - you were right again.
Applied them and updated the website and
Tom Lane wrote:
The original INT64 coding here is exact (at least for the common case
where fval is zero) but I'm not convinced that your revision can't
suffer from roundoff error.
Good point. I'll study this tonight; and either try to make a patch
that'll be exact where fval's zero or try to
Ron Mayer [EMAIL PROTECTED] writes:
Once this settles I suppose I should post a ECPG patch that's based
off of these Decode/Encode interval functions too?
Yeah, if you want. I think you'll find that the datetime code has
drifted far enough since ecpg forked it that you'll be looking at a
On Sat, Nov 1, 2008 at 3:42 PM, Ron Mayer [EMAIL PROTECTED] wrote:
# Patch 3: cleanup.patch
Fix rounding inconsistencies and refactor interval input/output code
Compile, testing and regression tests all checked out.
I've picked up on a few code style issues, fixes attached.
If I'm reading
Brendan Jurd [EMAIL PROTECTED] writes:
I *was* going to question the inconsistent use of a space between the
pointer qualifier and the argument name, for example:
...
But then I noticed that there's a lot of this going on in datetime.c,
some of it appears to predate your patches.
Any
Ron Mayer wrote:
Tom Lane wrote:
In fact, given that we are now
somewhat SQL-compliant on interval input, a GUC that selected
PG traditional, SQL-standard, or ISO 8601 interval output format seems
like it could be a good idea.
Attached are updated versions of the Interval patches
Ron Mayer wrote:
Ron Mayer wrote:
Tom Lane wrote:
In fact, given that we are now
somewhat SQL-compliant on interval input, a GUC that selected
PG traditional, SQL-standard, or ISO 8601 interval output format seems
like it could be a good idea.
Attached are updated versions of the
Ron Mayer wrote:
Ron Mayer wrote:
Ron Mayer wrote:
Tom Lane wrote:
In fact, given that we are now
somewhat SQL-compliant on interval input, a GUC that selected
PG traditional, SQL-standard, or ISO 8601 interval output format
seems
like it could be a good idea.
Attached are updated
13 matches
Mail list logo
