'iscachable' only partially solves premature constant coercion

I have finished installing the code changes associated with marking
functions 'iscachable' or not.  I had hoped that this change would
eliminate the problems we have with premature coercion of datetime
constants in column defaults and rules.  It turns out it doesn't :-(.
That's because there isn't any good way to postpone the evaluation of
a typinput function.  Since the argument of a typinput function is a
null-terminated C string, and not a 'text' or any other full-fledged
Postgres type, there is no way to construct an expression tree
representing runtime evaluation of the typinput function.  So, even
though the system knows it shouldn't evaluate the typinput function
before runtime, it has little choice.

We have talked about making 'C string' a genuine Postgres type, at
least to the extent of giving it an OID and making it representable
as a Const node.  If we did that then we could represent a typinput
function call by an expression tree and make this problem go away.
I'm not going to tackle that right now, though, since there are
higher-priority problems to deal with.

The current state of affairs is that if you write a constant of UNKNOWN
type (ie, an unadorned quoted constant), it'll get coerced to the
destination type just as soon as the system can figure out what that
type is.  So, it's still necessary to write "'now'::text" (or one of the
other syntaxes for type-casting) or "now()" as the default value for
a datetime column --- if you write unadorned 'now' then you will get
the time of table creation, same as before.

I am about to rip out and redo the crufty implementation of default and
constraint expressions, and I think that I can arrange for UNKNOWN
constants to remain UNKNOWN when they are stored into the pg_attrdef
table.  This would mean that what gets into pg_attrdef is just the
unadorned string 'now', and then the coercion of this to a particular
timestamp will occur when an INSERT statement that uses the default
is parsed.  So the right thing (approximately, anyway) should happen for
a typical run-of-the-mill INSERT.  The wrong thing will still happen
for an INSERT written in a rule --- its default will be established when
the rule is created.
        regards, tom lane