> [ CC'ing to hackers because this is getting into code problems. ]
Not sure I agree with that conclusion yet.
> Here's another inconsistency that Tatsuo found:
> test=> create table ff (x time default 'current_timestamp');
> ERROR: Bad time external representation 'current_timestamp'
Never was a feature, and not documented as such. CURRENT_TIMESTAMP (and
CURRENT_DATE and CURRENT_TIME; note lack of quotes) are defined by SQL9x
as specialty constants (they have some other term for them afaicr).
> test=> create table ff (x time default 'current');
> ERROR: Bad time external representation 'current'
Never was a feature, but sure seems like it should have been. How have
we missed all of those complaints about this over the last six years? ;)
We'll guess that 'current' was not one of the most utilized features of
the date/time types (which is one reason why I supported removing it).
> test=> create table ff (x time default 'now');
> CREATE
> test=> select current_timestamp;
> timestamptz
> -------------------------------
> 2001-11-13 22:49:50.607401-05
> (1 row)
>
> You can default a time to now, but not to current or current_timestamp.
>
> I believe this is happening because current is implemented as special
> timezones in datetime.c and timestamp.c, and current_timestamp is
> implemented in gram.y, while 'now' is a function.
Not sure what special time zones have to do with it (did you mean
"special timestamps"?). CURRENT_xxx has to be implemented in gram.y
since they are keywords, not quoted strings. 'now' is not a function,
though now() is; both 'now' and 'current' are special cases in the input
parser for the date/time data types, with one inconsistancy as noted
above. That will be fixed.
> Anyway, looks like confusion that should be fixed.
The documentation covers some of this, and Tom has pointed out
(presumably to encourage a contribution) that it hasn't been updated yet
for the most recent changes for 7.2. I expect to do so in the next
couple of weeks.
- Thomas