Обсуждение: pgsql-server/src backend/catalog/heap.c backen ...

CVSROOT:    /cvsroot
Module name:    pgsql-server
Changes by:    tgl@svr1.postgresql.org    03/07/29 14:21:28

Modified files:
    src/backend/catalog: heap.c
    src/backend/rewrite: rewriteHandler.c
    src/include/catalog: catversion.h

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'
    but in fact merely made the failure modes subtle rather than obvious.
    Per recent trouble report and followup discussion.

    initdb forced since there is a chance that stored default expressions
    will change.

> 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?

Chris

"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