From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mark Hollomon" <mhh(at)nortelnetworks(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Bug with views and defaults |
Date: | 2000-06-16 23:43:10 |
Message-ID: | 9399.961198990@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Mark Hollomon" <mhh(at)nortelnetworks(dot)com> writes:
> CREATE TABLE foo (
> name TEXT,
> type CHAR(1),
> when_added TIMESTAMP DEFAULT 'now'
> );
> CREATE VIEW mytype AS
> SELECT name, when_added FROM foo WHERE type = 'M';
> CREATE RULE mytype_insert AS
> ON INSERT TO mytype DO INSTEAD
> INSERT INTO foo (name, type) VALUES (NEW.name, 'M');
> Inserting directly into foo sets when_added to the current time.
> Inserting through the view sets it to what looks like the time of
> view creation.
This is a known and not readily fixable problem. It's far safer
to write the default for a timestamp column as now(), rather than
relying on a string literal not getting coerced to timestamp form
too soon. See
http://www.postgresql.org/mhonarc/pgsql-hackers/1999-10/msg00036.html
BTW, Bruce: it probably would be wise to have the FAQ's item 4.22
recommend now() and nothing else. 'now' has nothing much to recommend
it and there are still pitfalls like this one.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-06-17 00:06:49 | Re: Bug with views and defaults |
Previous Message | Tom Lane | 2000-06-16 23:30:25 | Re: Big 7.1 open items |