Re: [HACKERS] Problem with copying abstimes - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] Problem with copying abstimes
Date
Msg-id e68d0316d0c943a11881f77c10f5cbbc
Whole thread Raw
In response to [HACKERS] Problem with copying abstimes  (Ronald Baljeu <rjb@xs4all.nl>)
List pgsql-hackers
> Postgres needs something like the TO_CHAR(), TO_DATE() and
> TO_NUMBER() functions for converting and formating the various data types.

Has 'em, or will (see below).

> Why do we now have date, abstime and datetime?  Why not deprecate the old
> postgres date and abstime for v7.0 and rename the datetime to be the ansi type
> date type?  I realize that people will have to change scripts and code, but it
> happens, projects progress.  Try to keep the old stuff around and you end of
> with messes like the seg/offset PC memory hack. :)
>
> Datetime seems to be able to do everything the other two can, why not [lt]ighten
> up the code a bit?  Anyways, "Flexibility breeds bugs."

Naw, no flames, although I might like to postpone this discussion for a
while since v7.0 is not coming for a while. Anyway, I have an Ingres
background, and so implemented functions date_trunc() and date_part()
which presumably do things like to_number(). (Have other neat functions
like date_zone() which gives you any timezone you specify, ready to go
in the next release). Most commercial RDBMSes are pretty old now, and
probably wouldn't do things the same way if they could do it over. So,
neither Oracle nor Ingres are probably the best models for the right way
to do it, and I suppose Postgres is not trying to become an Oracle
look-alike but rather a modern, lean, try-to-do-it-the-sensible-way
system.

from glancing at the SQL92 docs posted at Berkeley, ANSI SQL92 seems to
specify 4 date/time types (with one variant):
1) date
2) time
3) timestamp and "timestamp with timezone"
4) interval

Of course, SQL92 was carefully designed to not break existing databases
too much, so might have some stuff which is a waste of time. I would
propose that for v7.0 we migrate to the ANSI SQL date/time terminology,
and have the existing datetime type migrate to become timestamp, and the
existing timespan type become interval. date and time would stay defined
and become more ANSI-like if not so already.

In keeping with Postgres' international outlook, I would propose that
timestamp always have a timezone associated with it, and that date and
time be simple and timezone-independent.

abstime has been used since the beginning of (Unix) time in the
internals of Postgres, but I would suggest that it might be deprecated
as a user-level type.

Other comments?

            - Tom

------------------------------

End of hackers-digest V1 #401
*****************************

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re[2]: [HACKERS] Re: [QUESTIONS] libpq++
Next
From: "Martin S. Utesch"
Date:
Subject: [HACKERS] Compile HELP for 'rint' needed (HPUX 9.01)