On Thu, Oct 19, 2006 at 10:36:29AM -0400, AgentM wrote:
> Only if each message is contained in its own transaction since now()
> is effectively a constant throughout a transaction. In this case, I
> would choose a surrogate key since it is likely that the table will
> be referenced.
See time
On Oct 19, 2006, at 10:30 , John D. Burger wrote:
cckramer wrote:
I have table for online chat system that keep messages sent
between users.
Question: is it okay to use timestamp as primary key, or there is
possibility of collision? (Meaning two processes may INSERT into
table
within s
cckramer wrote:
I have table for online chat system that keep messages sent between
users.
Question: is it okay to use timestamp as primary key, or there is
possibility of collision? (Meaning two processes may INSERT into table
within same millisecond.) It is a web application.
tometzky wr
Joe Kramer wrote:
Hello,
I have table for online chat system that keep messages sent between users.
CREATE TABLE chat_message
(
message_time timestamp without time zone NOT NULL DEFAULT now(),
Hmm - timestamp without time zone. So you don't actually care when the
message was sent? Or you kn
On Thu, 19 Oct 2006, Joe Kramer wrote:
> Question: is it okay to use timestamp as primary key, or there is
> possibility of collision? (Meaning two processes may INSERT into table
> within same millisecond.) It is a web application.
If your insert fail you can always try again after some random s
Hello,
I have table for online chat system that keep messages sent between users.
CREATE TABLE chat_message
(
message_time timestamp without time zone NOT NULL DEFAULT now(),
message_body text,
user_id_from bigint,
user_id_to bigint,
CONSTRAINT chat_message_pkey PRIMARY KEY (message_time)
)
