Niladic functions
The "Integrated Document" on the web page has the following paragraph in
the section "CREATE TABLE" in chapter 20.
In the current release (v6.4), Postgres evaluates all default expressions at
the time the table is defined. Hence, functions which are "non-cacheable"
such as CURRENT_TIMESTAMP may not produce the desired effect. For the
particular case of date/time types, one can work around this behavior by
using "DEFAULT TEXT 'now'" instead of "DEFAULT 'now'" or "DEFAULT
CURRENT_TIMESTAMP". This forces Postgres to consider the constant a string
type and then to convert the value to timestamp at runtime.
This appears to be untrue. Is this a change since 6.4 or is there
some cases where using CURRENT_TIMESTAMP will not do the expected thing?
Also, the title of the document (The PostgreSQL Development Team) seems
to be incorrect.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
The "Integrated Document" on the web page has the following paragraph
in the section "CREATE TABLE" in chapter 20.
In the current release (v6.4), Postgres evaluates all default
expressions at the time the table is defined. Hence, functions which
are "non-cacheable" such as CURRENT_TIMESTAMP may not produce the
desired effect. For the particular case of date/time types, one can
work around this behavior by using "DEFAULT TEXT 'now'" instead of
"DEFAULT 'now'" or "DEFAULT CURRENT_TIMESTAMP". This forces Postgres
to consider the constant a string type and then to convert the value
to timestamp at runtime.This appears to be untrue. Is this a change since 6.4 or is there
some cases where using CURRENT_TIMESTAMP will not do the expected
thing?
Sorry for being slow, but exactly which of the several assertions in the
above paragraph are not true? Just the DEFAULT CURRENT_TIMESTAMP
behavior?
Also, the title of the document (The PostgreSQL Development Team)
seems to be incorrect.
My browser shows that as the second line, just under the title
"PostgreSQL", as I intended. What browser are you using?
- Tom
Thus spake Thomas G. Lockhart
The "Integrated Document" on the web page has the following paragraph
in the section "CREATE TABLE" in chapter 20.
In the current release (v6.4), Postgres evaluates all default
expressions at the time the table is defined. Hence, functions which
are "non-cacheable" such as CURRENT_TIMESTAMP may not produce the
desired effect. For the particular case of date/time types, one can
work around this behavior by using "DEFAULT TEXT 'now'" instead of
"DEFAULT 'now'" or "DEFAULT CURRENT_TIMESTAMP". This forces Postgres
to consider the constant a string type and then to convert the value
to timestamp at runtime.This appears to be untrue. Is this a change since 6.4 or is there
some cases where using CURRENT_TIMESTAMP will not do the expected
thing?Sorry for being slow, but exactly which of the several assertions in the
above paragraph are not true? Just the DEFAULT CURRENT_TIMESTAMP
behavior?
Yes. This paragraph says that CURRENT_TIMESTAMP is evaluated at the time
the table is defined yet I tested this with a current version and it
actually gets evaluated at INSERT time.
Also, the title of the document (The PostgreSQL Development Team)
seems to be incorrect.My browser shows that as the second line, just under the title
"PostgreSQL", as I intended. What browser are you using?
Sorry, my misunderstanding. I didn't realize that PostgreSQL was the
title of this particular document. Anyway, the link to this page is
"Integrated Document" so there is a small inconsistency.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.This appears to be untrue. Is this a change since 6.4 or is there
some cases where using CURRENT_TIMESTAMP will not do the expected
thing?This paragraph says that CURRENT_TIMESTAMP is evaluated at the time
the table is defined yet I tested this with a current version and it
actually gets evaluated at INSERT time.
You are right; I had changed the parser to force a string into the parse
tree rather than a constant. Would you be interested in sending patches
for the docs? :)
Also, the title of the document (The PostgreSQL Development Team)
seems to be incorrect.My browser shows that as the second line, just under the title
"PostgreSQL", as I intended. What browser are you using?Sorry, my misunderstanding. I didn't realize that PostgreSQL was the
title of this particular document. Anyway, the link to this page is
"Integrated Document" so there is a small inconsistency.
The problem is that this is a document integrated from all of the other
documents for purposes of HTML formatting and browsing. I wanted to make
clear that all of the information appears somewhere in the other
documents.
- Tom
Thus spake Thomas G. Lockhart
This paragraph says that CURRENT_TIMESTAMP is evaluated at the time
the table is defined yet I tested this with a current version and it
actually gets evaluated at INSERT time.You are right; I had changed the parser to force a string into the parse
tree rather than a constant. Would you be interested in sending patches
for the docs? :)
I can't find the source doc in the distribution but it's pretty simple.
Just remove that whole paragraph.
Sorry, my misunderstanding. I didn't realize that PostgreSQL was the
title of this particular document. Anyway, the link to this page is
"Integrated Document" so there is a small inconsistency.The problem is that this is a document integrated from all of the other
documents for purposes of HTML formatting and browsing. I wanted to make
clear that all of the information appears somewhere in the other
documents.
Hence the title on the referring page. How about changing the title on
the page itself to reflect that as well? Something like;
"PostgreSQL Integrated Development Document"
or some such. No biggie but it makes it easier to remember how you got
to the document you are reading.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
Can someone comment on this?
The "Integrated Document" on the web page has the following paragraph in
the section "CREATE TABLE" in chapter 20.In the current release (v6.4), Postgres evaluates all default expressions at
the time the table is defined. Hence, functions which are "non-cacheable"
such as CURRENT_TIMESTAMP may not produce the desired effect. For the
particular case of date/time types, one can work around this behavior by
using "DEFAULT TEXT 'now'" instead of "DEFAULT 'now'" or "DEFAULT
CURRENT_TIMESTAMP". This forces Postgres to consider the constant a string
type and then to convert the value to timestamp at runtime.This appears to be untrue. Is this a change since 6.4 or is there
some cases where using CURRENT_TIMESTAMP will not do the expected thing?Also, the title of the document (The PostgreSQL Development Team) seems
to be incorrect.-- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Can someone comment on this?
Resolved.
- Tom
The "Integrated Document" on the web page has the following paragraph in
the section "CREATE TABLE" in chapter 20.In the current release (v6.4), Postgres evaluates all default
expressions...
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Was this addressed?
The "Integrated Document" on the web page has the following paragraph in
the section "CREATE TABLE" in chapter 20.In the current release (v6.4), Postgres evaluates all default expressions at
the time the table is defined. Hence, functions which are "non-cacheable"
such as CURRENT_TIMESTAMP may not produce the desired effect. For the
particular case of date/time types, one can work around this behavior by
using "DEFAULT TEXT 'now'" instead of "DEFAULT 'now'" or "DEFAULT
CURRENT_TIMESTAMP". This forces Postgres to consider the constant a string
type and then to convert the value to timestamp at runtime.This appears to be untrue. Is this a change since 6.4 or is there
some cases where using CURRENT_TIMESTAMP will not do the expected thing?Also, the title of the document (The PostgreSQL Development Team) seems
to be incorrect.-- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Was this addressed?
Yes.
- Thomas
The "Integrated Document" on the web page has the following paragraph in
the section "CREATE TABLE" in chapter 20.In the current release (v6.4), Postgres evaluates all default expressions at
the time the table is defined. Hence, functions which are "non-cacheable"
such as CURRENT_TIMESTAMP may not produce the desired effect. For the
particular case of date/time types, one can work around this behavior by
using "DEFAULT TEXT 'now'" instead of "DEFAULT 'now'" or "DEFAULT
CURRENT_TIMESTAMP". This forces Postgres to consider the constant a string
type and then to convert the value to timestamp at runtime.This appears to be untrue. Is this a change since 6.4 or is there
some cases where using CURRENT_TIMESTAMP will not do the expected thing?Also, the title of the document (The PostgreSQL Development Team) seems
to be incorrect.
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California