Michael Glaesemann <[EMAIL PROTECTED]> writes:
> Well, you can't get better than microsecond precision with timestamps
> in Postgres. And the only way you can rely on that level of precision
> is to compile with --enable-integer-datetimes.
There is more precision in there, but the output routi
If I reduce the precision to 3 for the timestamps it appears to work
although it makes me nervous.
With float timestamps, you're fooling yourself if you think those
numbers past the decimal are reliable.
Should I just recompile to use integer datetimes? I would like to
have at least micros
On Jan 22, 2008, at 3:05 , Stuart Brooks wrote:
If I reduce the precision to 3 for the timestamps it appears to
work although it makes me nervous.
With float timestamps, you're fooling yourself if you think those
numbers past the decimal are reliable.
Should I just recompile to use integ
silly_sad wrote:
id default value is always set by the trigger before insert on each
table for each row.
The particular subproblem is to
insert one record into ttt1
and then insert corresponding record into ttt,
___This is the place to use currval.
I'd be tempted to turn it the other way ar
On Tue, Jan 22, 2008 at 10:16:30AM +0300, silly_sad wrote:
> INSERT INTO ttt (a,b) SELECT currval('ttt_id_seq'), 'const' FROM ttt2;
> Where the trigger before insert on ttt is defined and this trigger calls
> nextval('ttt_id_seq').
> I was surprised having different values of currval() in ttt.a
>
Richard Huxton wrote:
sad wrote:
Richard Huxton wrote:
Then this is the question on the execution order of the statement
INSERT...SELECT...
You'll want "Overview of PostgreSQL internals" then
http://www.postgresql.org/docs/8.2/static/overview.html
What do you think should happen?
I had
sad wrote:
Richard Huxton wrote:
Then this is the question on the execution order of the statement
INSERT...SELECT...
You'll want "Overview of PostgreSQL internals" then
http://www.postgresql.org/docs/8.2/static/overview.html
What do you think should happen?
I had expected all the currva
sad wrote:
Guillaume Lelarge wrote:
sad wrote:
A. Kretschmer wrote:
is it expected that the currval() changes its value between calls
within one statement ?
Conclusion, don't call nextval() within a TRIGGER, and insert either
nextval() for the column or omit this column.
I only note that
Richard Huxton wrote:
sad wrote:
A. Kretschmer wrote:
is it expected that the currval() changes its value between calls
within one statement ?
Conclusion, don't call nextval() within a TRIGGER, and insert either
nextval() for the column or omit this column.
I only note that i still want t
sad wrote:
A. Kretschmer wrote:
is it expected that the currval() changes its value between calls
within one statement ?
Conclusion, don't call nextval() within a TRIGGER, and insert either
nextval() for the column or omit this column.
I only note that i still want to discuss the titled pr
sad wrote:
A. Kretschmer wrote:
is it expected that the currval() changes its value between calls
within one statement ?
Conclusion, don't call nextval() within a TRIGGER, and insert either
nextval() for the column or omit this column.
I only note that i still want to discuss the titled pr
I have a problem in comparing a TIMESTAMP field with a timestamp
literal. I presume it is to do with the floating point representation of
the timestamp but I was wondering if there is an easy work around
without having to recompile postgres to use integer datetimes.
Basically if I issue a "SEL
12 matches
Mail list logo
