Thomas Lockhart <lockhart@fourpalms.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:Considerinterpreting a function call as a trivial(binary-compatible) type coercion
afterfailing to find an exactmatch in pg_proc, but before considering interpretations thatinvolve a function call with
oneor more argument type coercions. This avoids surprises wherein what looks like a type coercion isinterpreted as
coercingto some third type and then to thedestination type, as in Dave Blasby's bug report of 3-Oct-01. Seesubsequent
discussionin 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