> Thomas, any status on this? If not, I should add it to the TODO list.
Well, sure, there is *always* status ;)
I started coding a couple of days ago. So far, no showstoppers.
There are two related issues:
1) I should recode TIME WITH TIME ZONE to conform to SQL99. I had done
it originally wi
Thomas, any status on this? If not, I should add it to the TODO list.
> > Is this a TODO item?
>
> Sure, but I'd hate to have all of these individual items showing up as
> separate things in some ToDo list, since it won't paint a coherent
> picture of where things are headed.
>
> I'm plannin
> Is this a TODO item?
Sure, but I'd hate to have all of these individual items showing up as
separate things in some ToDo list, since it won't paint a coherent
picture of where things are headed.
I'm planning on doing some work on timestamp, which will include:
o support for "ISO variants" on
> > I already commented what I thought about this: the current type is not
> > either of the SQL-compatible timestamp types, and if we want to support
> > the SQL-compatible semantics then we need three types, not two.
>
> Right, that was clear even to me ;)
>
> We were on that path for quite so
> > I believe everyone already agreed that 'current' should be removed.
> > 'invalid' seems somewhat redundant with NULL, so I wouldn't object to
> > taking it out; on the other hand, is it hurting anything? Also, it
> > seems a bad idea to remove it from timestamp if we leave it in abstime;
> >
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> The description in pg_dump was chosen to assist with a transition in the
> next version of PostgreSQL to having available a true "no time zone"
> timestamp, leaving the current implementation as the "time zone aware"
> type. I'm concerned about changin
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Thomas Lockhart writes:
>> SQL9x "timestamp" has no notion of time zones. PostgreSQL "timestamp"
>> does.
> AFAICT, it does not. The value is stored in UTC (more or less) and is
> converted to the local time zone for display. But a data type is def
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am confused what you are suggesting here.
*** src/backend/utils/adt/format_type.c.origWed May 23 18:10:19 2001
--- src/backend/utils/adt/format_type.c Mon Jun 18 21:41:53 2001
***
*** 178,184
break;
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Very few people know the standards stuff so it seems we should just call
> it timestamp and do the best we can. Basically by mentioning "with
> timezone" we are making the standards people happy but confusing our
> users.
I don't believe we're making a
> Let's switch 'timestamp with time zone' back to 'timestamp'. This just
> makes no sense.
Imho it only makes no sense, since the impl does not conform to standard :-(
The "with time zone" requests, that the client timezone be stored in the row.
The "timestamp" wants no timezone arithmetic/input
10 matches
Mail list logo
