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, y
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
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 eve
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 in
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'
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-
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 v
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 (pgsql-hackers@postgre
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
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
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
http://www.postgresql.org/abo
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
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
config
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 out
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 ch
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
depreca
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 serve
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?
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 P
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 se
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 float
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
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
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
> implemen
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 hav
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:
(1
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 i
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 an
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.
>
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 bu
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). N
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
--
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 d
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 microse
34 matches
Mail list logo
