Re: Timestamp conversion can't use index

Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> timestamp('stringy time')
> may not be good, but I would think that
> timestamp 'timey time'
> should let the optimizer use indices just fine.

Yup. Possibly this should be noted in the FAQ?

Actually,
timestamp('stringy time')
doesn't work at all anymore in 7.2, unless you doublequote the name:

regression=# select timestamp('now');
ERROR: parser: parse error at or near "'"
regression=# select "timestamp"('now');
timestamp
----------------------------
2001-12-26 12:18:07.008337
(1 row)

Another interesting factoid is that "timestamp"('now') does indeed
produce a constant in 7.2, not a runtime evaluation of text_timestamp.
text_timestamp is still considered noncachable, but the expression is
considered to represent timestamp 'now' and not a call of text_timestamp,
presumably because of this change:

2001-10-04 18:06 tgl

* doc/src/sgml/typeconv.sgml, src/backend/commands/indexcmds.c,
src/backend/parser/parse_func.c, src/include/parser/parse_func.h:
Consider interpreting a function call as a trivial
(binary-compatible) type coercion after failing to find an exact
match in pg_proc, but before considering interpretations that
involve a function call with one or more argument type coercions.
This avoids surprises wherein what looks like a type coercion is
interpreted as coercing to some third type and then to the
destination type, as in Dave Blasby's bug report of 3-Oct-01. See
subsequent discussion in pghackers.

So there's more here than meets the eye, but the syntax change from
7.1 to 7.2 is definitely going to warrant a FAQ entry, IMHO.

regards, tom lane