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) It means we need to maintain two sets of code, with a corresponding
increase in the maintenance burden, the probability of introducing bugs,
etc., and making datetime behavior more difficult to test.

(2) In general, I think it is a fundamentally *bad* idea to have the
semantics of a builtin data type differ subtly depending on the value of
a configure parameter. It makes writing portable applications more
difficult, and can introduce hard-to-fix bugs.

So, are there any corresponding benefits to providing both FP and
integer datetimes? AFAIK the following differences in user-visible
behavior exist:

* integer timestamps have the same precision over their entire range
(microsecond precision), whereas FP timestamps do not. This is
clearly an advantage for integer timestamps.

* integer timestamps have a smaller range than FP timestamps
(294276 AD vs. 5874897 AD). Are there actually applications
that use timestamps larger than 300,000 AD?

Unless there are lots of applications that need timestamps over such a
large range, ISTM integer datetimes are the better long-term approach,
and I don't see how the FP-based datetime code justifies the maintenance
burden. 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?

Therefore, I propose that we make integer datetimes the default (perhaps
for 8.4), and then eventually remove the floating-point datetime code.

Comments?

-Neil

P.S. One thing to verify is that the performance of integer datetimes is
no worse than the perf. of FP datetimes. I'd intuitively expect this to
be true, but it would be worth investigating.



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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 a range of about 1 hour (or
about 1 month, if you reduce it to millisecond precision), which would
make it totally useless.

If we wanted to move toward requiring a 64-bit type, we should put some
big warning into configure now that yells at the user if they don't
have that type. And if no one complains, we can make it a requirement
in a later release.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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 a 32-bit type would have a range of about 1 hour (or
> about 1 month, if you reduce it to millisecond precision), which would
> make it totally useless.
>
> If we wanted to move toward requiring a 64-bit type, we should put some
> big warning into configure now that yells at the user if they don't
> have that type. And if no one complains, we can make it a requirement
> in a later release.
>


Can we discover anything useful from existing configure logs? If so, maybe
we can survey the buildfarm database.

Incidentally, use of integer datetimes has been in the default config set
on the buildfarm from day one, because it seems to me far saner, in
principle, to use fixed precision for them, so I cerainly agree with
Neil's goal.

cheers

andrew


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Peter Eisentraut <peter_e@gmx.net> 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 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. The
datetime code seems relatively stable at this point, so the maintenance
overhead of the code as it stands is not high.

I'm not necessarily opposed to changing the default configure selection,
but I am opposed to removing the FP code entirely.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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 this dependency? Can we really
avoid a dependency on a 64-bit integral type in the long run?

> 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
deprecating the FP code (but keeping it around as a configure option).
Are there any objections to doing this for 8.3?

-Neil



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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 floating point
optimalization (-fast switch in Sun Studio) for server compilation and
client will be connected from another machine with standard floating
point behavior. Result could be wrong.

>
> P.S. One thing to verify is that the performance of integer datetimes is
> no worse than the perf. of FP datetimes. I'd intuitively expect this to
> be true, but it would be worth investigating.

Some multi core/thread CPUs has only one FPU (e.g. Niagara).


Zdenek

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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. For example if somebody use floating point
> optimalization (-fast switch in Sun Studio) for server compilation and
> client will be connected from another machine with standard floating
> point behavior. Result could be wrong.

What? We don't pass float as a binary to clients. The client can be
any OS.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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 PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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 <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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
> configuration, right?
>
>

Certainly the client and server must have the same notion of the binary
format.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate