jon...@xmission.com writes:
> CREATE UNIQUE INDEX one_entry_per_submitter_per_month ON table_entry
> (submitter_id , date_trunc('month',entry_timestamp));
> runs into
> ERROR: functions in index expression must be marked IMMUTABLE.
> If I'm reading this correctly, date_trunc is not IMMUTABLE an
Seems like you would be a lot better off enforcing this with a unique
index on (submitter_id, date_trunc('month',entry_timestamp)). The above
not only doesn't provide any feedback, it's got serious race-condition
problems.
Unfortunately, it didn't work.
CREATE UNIQUE INDEX one_entry_per_submit
Seems like you would be a lot better off enforcing this with a unique
index on (submitter_id, date_trunc('month',entry_timestamp)). The above
not only doesn't provide any feedback, it's got serious race-condition
problems.
I'll take a look at using an index to do this. The trigger is an ugly
jon...@xmission.com writes:
> Greetings. I noticed an interesting behavior when using a PL/pgSQL
> trigger. I'm running PostgreSQL 8.3. The trigger function checks a
> newly inserted or updated row for a type of uniqueness. Specifically,
> each row in the table has a submitter id and an e
Greetings. I noticed an interesting behavior when using a PL/pgSQL
trigger. I'm running PostgreSQL 8.3. The trigger function checks a
newly inserted or updated row for a type of uniqueness. Specifically,
each row in the table has a submitter id and an entry timestamp. No
two rows can h
