Re: pgsql-server/src backend/catalog/heap.c backen ...

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
>> Log message:
>> Coerce unknown-literal-constant default values to the column type during
>> CREATE TABLE (or ALTER TABLE SET DEFAULT), rather than postponing it to
>> the time that the default is inserted into an INSERT command by the
>> rewriter.  This reverses an old decision that was intended to make the
>> world safe for writing
>> f1 timestamp default 'now'

> Does that mean that default current_timestamp will work?

It did, still does, and always will ;-).  The case that we are no longer
supporting is with the simple unknown-literal-string-constant 'now'.
In 7.3 and before you could do this:

regression=# create table foo (
regression(# f1 timestamp default 'now',
regression(# f2 timestamp default timestamp 'now');
CREATE TABLE

and the first case would do what you were expecting (at least until you
got into prepared statements or plpgsql functions).  The second case
would freeze the timestamp too soon, and was documented that way:

regression=# \d foo
                                            Table "public.foo"
 Column |            Type             |                             Modifiers
--------+-----------------------------+-------------------------------------------------------------------
 f1     | timestamp without time zone | default 'now'
 f2     | timestamp without time zone | default '2003-07-30 10:32:24.762288'::timestamp without time zone

regression=#

As of CVS tip, both cases work alike, namely the timestamp is frozen at
CREATE TABLE.

            regards, tom lane