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