Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of mar mar 15 11:42:06 -0300 2011:
> > "Kevin Grittner" writes:
> > > Tom Lane wrote:
> > >> Dimitri Fontaine writes:
> > >>> Would it help moving toward Leap Second support, and is this
> > >>> something we want to have?
> >
> > >> IMO w
Excerpts from Tom Lane's message of mar mar 15 11:42:06 -0300 2011:
> "Kevin Grittner" writes:
> > Tom Lane wrote:
> >> Dimitri Fontaine writes:
> >>> Would it help moving toward Leap Second support, and is this
> >>> something we want to have?
>
> >> IMO we don't want to have that, as it would
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Dimitri Fontaine writes:
>>> Would it help moving toward Leap Second support, and is this
>>> something we want to have?
>> IMO we don't want to have that, as it would completely bollix
>> datetime calculations of all kinds. You couldn't even count
Tom Lane wrote:
> Dimitri Fontaine writes:
>> Would it help moving toward Leap Second support, and is this
>> something we want to have?
>
> IMO we don't want to have that, as it would completely bollix
> datetime calculations of all kinds. You couldn't even count on
> stored timestamps not cha
Dimitri Fontaine writes:
> Would it help moving toward Leap Second support, and is this something
> we want to have?
IMO we don't want to have that, as it would completely bollix datetime
calculations of all kinds. You couldn't even count on stored timestamps
not changing their meaning.
Simon Riggs writes:
> On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
>> On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
>> > It has bothered me that many of our time routines use special magic
>> > constants for time values, e.g. 24, 12, 60, etc.
>> >
>> > The attached patch
Bruce Momjian wrote:
> Let me also add that I realize I am often a royal pain in the
> neck.
It really stands out compared to all the timid shrinking violets who
post here. ;-)
Seriously, I've always found that a group works best with a mix of
personalities with their various approaches, s
Bruce Momjian wrote:
> > Yeah, I agree. And I do think that there is also some value of having
> > constants for SECS_PER_MINUTE and MINUTES_PER_HOUR, because otherwise
> > it can be unclear what 60 means in a particular context. We're at
> > the high end of what I consider reasonable in terms o
Robert Haas wrote:
> On Mon, Mar 14, 2011 at 12:01 PM, Tom Lane wrote:
> > "Kevin Grittner" writes:
> >> My first reaction that this change was about a net wash in
> >> readability for me -- in a couple places it might save me a few
> >> moments thinking about what the number was meant to represe
On Mon, Mar 14, 2011 at 12:01 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> My first reaction that this change was about a net wash in
>> readability for me -- in a couple places it might save me a few
>> moments thinking about what the number was meant to represent,
>> balanced against follo
"Kevin Grittner" writes:
> My first reaction that this change was about a net wash in
> readability for me -- in a couple places it might save me a few
> moments thinking about what the number was meant to represent,
> balanced against following the ctag back to the #define to see what
> number wa
Bruce Momjian wrote:
> Tom Lane wrote:
>> some of them are pretty darn questionable because the underlying
>> number *isn't* as well defined as all that.
>
> The macro does allow us to centralize comments on their
> imprecision,
> e.g.:
>
> /*
> * DAYS_PER_MONTH is very imprecise. The more
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Mar 14, 2011 at 4:22 AM, Simon Riggs wrote:
> >> On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
> >>> I think it's much clearer with the plain numbers.
>
> >> Yeh. It's not like the values 24, 12 or 60 were going to change.
>
> > I h
Robert Haas writes:
> On Mon, Mar 14, 2011 at 4:22 AM, Simon Riggs wrote:
>> On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
>>> I think it's much clearer with the plain numbers.
>> Yeh. It's not like the values 24, 12 or 60 were going to change.
> I had the same thought. OTOH, even
On Mon, 2011-03-14 at 10:42 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
> > > On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
> > > > It has bothered me that many of our time routines use special magic
> > > > constants for
Simon Riggs wrote:
> On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
> > On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
> > > It has bothered me that many of our time routines use special magic
> > > constants for time values, e.g. 24, 12, 60, etc.
> > >
> > > The attached patc
Robert Haas wrote:
> On Mon, Mar 14, 2011 at 4:22 AM, Simon Riggs wrote:
> > On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
> >> On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
> >> > It has bothered me that many of our time routines use special magic
> >> > constants for time
On 03/14/2011 09:25 AM, Robert Haas wrote:
On Mon, Mar 14, 2011 at 4:22 AM, Simon Riggs wrote:
On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
It has bothered me that many of our time routines use special magic
constants for
On Mon, Mar 14, 2011 at 4:22 AM, Simon Riggs wrote:
> On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
>> On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
>> > It has bothered me that many of our time routines use special magic
>> > constants for time values, e.g. 24, 12, 60, etc.
On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
> On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
> > It has bothered me that many of our time routines use special magic
> > constants for time values, e.g. 24, 12, 60, etc.
> >
> > The attached patch changes these magic constants
On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
> It has bothered me that many of our time routines use special magic
> constants for time values, e.g. 24, 12, 60, etc.
>
> The attached patch changes these magic constants to macros to clarify
> the code. I would like to apply this for 9.1
Applied.
---
Bruce Momjian wrote:
> It has bothered me that many of our time routines use special magic
> constants for time values, e.g. 24, 12, 60, etc.
>
> The attached patch changes these magic constants to macros to cl
Bruce Momjian wrote:
> Christopher Browne wrote:
> > On Fri, Mar 11, 2011 at 12:50 PM, Bruce Momjian wrote:
> > > It has bothered me that many of our time routines use special magic
> > > constants for time values, e.g. 24, 12, 60, etc.
> > >
> > > The attached patch changes these magic constants
Christopher Browne wrote:
> On Fri, Mar 11, 2011 at 12:50 PM, Bruce Momjian wrote:
> > It has bothered me that many of our time routines use special magic
> > constants for time values, e.g. 24, 12, 60, etc.
> >
> > The attached patch changes these magic constants to macros to clarify
> > the code
On Fri, Mar 11, 2011 at 12:50 PM, Bruce Momjian wrote:
> It has bothered me that many of our time routines use special magic
> constants for time values, e.g. 24, 12, 60, etc.
>
> The attached patch changes these magic constants to macros to clarify
> the code. I would like to apply this for 9.1
It has bothered me that many of our time routines use special magic
constants for time values, e.g. 24, 12, 60, etc.
The attached patch changes these magic constants to macros to clarify
the code. I would like to apply this for 9.1 as a cleanup.
--
Bruce Momjian http://momjian.us
E
26 matches
Mail list logo
