Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane napsal(a):
This is not happening, at least not without 100 times more work than
anyone has shown willingness to put into the issue.
I understand your arguments, but it is important for in-place upgrade.
No, it is not,
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
The result will be two datatypes datetime and timestamp_int or timestamp_float.
This is not happening, at least not without 100 times more work than
anyone has shown willingness to put into the issue. It seems fairly
clear that
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane napsal(a):
This is not happening, at least not without 100 times more work than
anyone has shown willingness to put into the issue.
I understand your arguments, but it is important for in-place upgrade.
No, it is not, you merely need to be
Tom Lane napsal(a):
Alvaro Herrera [EMAIL PROTECTED] writes:
Neil Conway wrote:
Sure -- I sent in a patch earlier, but I'll post an updated version
shortly.
Hmm, I mean just switching the default value in configure.in ... is
there anything else that needs doing at this point?
Well, that's
Zdenek Kotala [EMAIL PROTECTED] writes:
The result will be two datatypes datetime and timestamp_int or
timestamp_float.
This is not happening, at least not without 100 times more work than
anyone has shown willingness to put into the issue. It seems fairly
clear that everyone thinks the int64
Neil Conway wrote:
Therefore, I propose that we make integer datetimes the default (perhaps
for 8.4), and then eventually remove the floating-point datetime code.
Neil, you're on the loop for changing the default in configure. Want to
do the honors?
--
Alvaro Herrera
On Thu, 2008-03-20 at 20:05 -0300, Alvaro Herrera wrote:
Neil, you're on the loop for changing the default in configure. Want to
do the honors?
Sure -- I sent in a patch earlier, but I'll post an updated version
shortly.
-Neil
--
Sent via pgsql-hackers mailing list
Neil Conway wrote:
On Thu, 2008-03-20 at 20:05 -0300, Alvaro Herrera wrote:
Neil, you're on the loop for changing the default in configure. Want to
do the honors?
Sure -- I sent in a patch earlier, but I'll post an updated version
shortly.
Hmm, I mean just switching the default value in
Alvaro Herrera [EMAIL PROTECTED] writes:
Neil Conway wrote:
Sure -- I sent in a patch earlier, but I'll post an updated version
shortly.
Hmm, I mean just switching the default value in configure.in ... is
there anything else that needs doing at this point?
Well, that's hardly a one-liner.
Are we agreed to wait for 8.4 for this?
---
Neil Conway wrote:
What is the reasoning behind having two different implementations of the
datetime types, with slightly different behavior? Do we intend to keep
supporting
On Wed, 2007-16-05 at 11:25 -0400, Bruce Momjian wrote:
Are we agreed to wait for 8.4 for this?
Yes.
-Neil
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Neil Conway wrote:
What is the reasoning behind having two different implementations of the
datetime types, with
Bruce Momjian wrote:
Neil Conway wrote:
On Sat, 2007-05-05 at 20:52 -0400, Bruce Momjian wrote:
What? We don't pass float as a binary to clients.
Sure we do, if the client is sending or receiving data in binary format.
But in those cases, we assume the client and server have the same
On May 5, 2007, at 10:38 AM, Neil Conway wrote:
On Sat, 2007-05-05 at 11:03 -0400, Tom Lane wrote:
I'm not necessarily opposed to changing the default configure
selection,
but I am opposed to removing the FP code entirely.
I would be satisfied with changing the default to integer and
Jim Nasby wrote:
On May 5, 2007, at 10:38 AM, Neil Conway wrote:
On Sat, 2007-05-05 at 11:03 -0400, Tom Lane wrote:
I'm not necessarily opposed to changing the default configure
selection,
but I am opposed to removing the FP code entirely.
I would be satisfied with changing the
On Sun, 2007-06-05 at 13:09 -0400, Bruce Momjian wrote:
Also, are we sure we can load a dump that used the float format? What
happens for a date out of int8 range?
AFAIK we should always be able to reload timestamp values that are in
the legal range for an int8-based timestamp. For values
What is the reasoning behind having two different implementations of the
datetime types, with slightly different behavior? Do we intend to keep
supporting both FP- and integer-based datetimes indefinitely?
Clearly, there are some costs associated with maintaining two different
implementations:
Neil Conway wrote:
Notably, the FP datetime code doesn't depend on having a
functional int64 type, but in 2007, are there really any platforms we
care about that don't have such a type?
That is really the only question, AFAIR. The integer datetimes
implementation on a 32-bit type would have
Peter Eisentraut wrote:
Neil Conway wrote:
Notably, the FP datetime code doesn't depend on having a
functional int64 type, but in 2007, are there really any platforms we
care about that don't have such a type?
That is really the only question, AFAIR. The integer datetimes
implementation on
Peter Eisentraut [EMAIL PROTECTED] writes:
Neil Conway wrote:
Notably, the FP datetime code doesn't depend on having a
functional int64 type, but in 2007, are there really any platforms we
care about that don't have such a type?
That is really the only question, AFAIR.
We've so far managed
On Sat, 2007-05-05 at 11:03 -0400, Tom Lane wrote:
We've so far managed to avoid having any hard dependency on a working
int64 type, but this would certainly be one. I don't really think the
code-size-reduction argument is strong enough to justify that.
What benefit do we get from avoiding
Neil Conway wrote:
So, are there any corresponding benefits to providing both FP and
integer datetimes? AFAIK the following differences in user-visible
behavior exist:
There should be also problem with floating point implementation on
client and server side. For example if somebody use
Zdenek Kotala wrote:
Neil Conway wrote:
So, are there any corresponding benefits to providing both FP and
integer datetimes? AFAIK the following differences in user-visible
behavior exist:
There should be also problem with floating point implementation on
client and server side.
On Sat, 2007-05-05 at 20:52 -0400, Bruce Momjian wrote:
What? We don't pass float as a binary to clients.
Sure we do, if the client is sending or receiving data in binary format.
-Neil
---(end of broadcast)---
TIP 7: You can help support the
Neil Conway wrote:
On Sat, 2007-05-05 at 20:52 -0400, Bruce Momjian wrote:
What? We don't pass float as a binary to clients.
Sure we do, if the client is sending or receiving data in binary format.
But in those cases, we assume the client and server have the same
configuration, right?
--
Bruce Momjian wrote:
Neil Conway wrote:
On Sat, 2007-05-05 at 20:52 -0400, Bruce Momjian wrote:
What? We don't pass float as a binary to clients.
Sure we do, if the client is sending or receiving data in binary format.
But in those cases, we assume the client and
OK, mention removed. We can always re-add it if we find we need to warn
people away from integer timestamps again.
---
Magnus Hagander wrote:
On Wed, Feb 14, 2007 at 12:38:12PM -0500, Andrew Dunstan wrote:
Tom Lane
Our docs for the integer datetime option says:
Use 64-bit integer storage for datetimes and intervals, rather than the
default floating-point storage. This reduces the range of representable
values but guarantees microsecond precision across the full range (see
Section 8.5 for more information).
Magnus Hagander [EMAIL PROTECTED] writes:
Our docs for the integer datetime option says:
Note also that the integer datetimes
code is newer than the floating-point code, and we still find bugs in it
from time to time.
Is the last sentence about bugs really true anymore? At least the
On Wed, Feb 14, 2007 at 11:27:31AM -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Our docs for the integer datetime option says:
Note also that the integer datetimes
code is newer than the floating-point code, and we still find bugs in it
from time to time.
Is the
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Our docs for the integer datetime option says:
Note also that the integer datetimes
code is newer than the floating-point code, and we still find bugs in it
from time to time.
Is the last sentence about bugs really true
On Wed, Feb 14, 2007 at 12:38:12PM -0500, Andrew Dunstan wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Our docs for the integer datetime option says:
Note also that the integer datetimes
code is newer than the floating-point code, and we still find bugs in it
from time
Has any thought been given to making integer datetimes the default on
platforms that support it? Are there any performance implications? I saw
the Tom Lane raised this when it was added, and it looks like the
decision was deferred. I know that, ceteris paribus, I would rather have
fixed
Andrew Dunstan [EMAIL PROTECTED] writes:
Has any thought been given to making integer datetimes the default on
platforms that support it? Are there any performance implications?
I don't know that anyone's done any serious performance comparisons.
My guess is there wouldn't be a noticeable
Tom Lane wrote:
I'm probably going to add the flag enabling it to the default
buildfarm setup.
This should be selected for some buildfarm members but not all, just
like other configuration options.
We're very democratic - every member gets to choose their own config ;-)
cheers
andrew
35 matches
Mail list logo
