> Thomas, can we change the description to just 'timestamp'?
Sure, we can do anything we want. I don't agree with all of the points
raised, and in particular disagree with the characterization of our
current "timestamp" type as having no concept of time zones, although it
is true that it has no concept of "sticky time zones" which travel with
the data value.
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 changing the current choice in the absence of
thought about this issue.
istm that if we dump timestamps which have time zone fields (which at
the moment all do), trying to read them back in as plain-vanilla SQL92
"timestamp" might result in an error condition, leading to dump/restore
problems. Or maybe it would be appropriate for a "time zone free" type
to just ignore time zone info in input? If so, upgrading wouldn't be as
big an issue, and just the upgraded schema would need to be
considered...
On a related note, I've been thinking about removing the following
features from our current "timestamp":
o timestamp 'invalid' - an interesting concept which might actually be
useful for the original abstime type since it has such a limited range,
but not generally useful for timestamp. I'd suggesting leaving it in for
abstime, at least for now.
o timestamp 'current' - another interesting concept not likely used by
anyone, and causing conniptions for our optimizer (one cannot cache
results for datasets containing this value).
Comments?
- Thomas