| From: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> |
|---|---|
| To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
| Cc: | David Fetter <david(at)fetter(dot)org>, blackwater dev <blackwaterdev(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: mysql replace in postgreSQL? |
| Date: | 2005-11-03 10:04:19 |
| Message-ID: | 5.2.1.1.1.20051103175440.03feceb0@localhost |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
At 12:28 AM 11/2/2005 -0500, Jan Wieck wrote:
>Using REPLACE INTO at one place and creating duplicates on purpose in
>another seems to make zero sense to me. Until one can explain the reason
>for that to me, I claim that a UNIQUE constraint on such key is a logical
>consequence.
I believe it is better to tell people to use UNIQUE constraints to avoid
duplicates than to tell them to use a particular stored procedure. I was
just pointing out that the "magic" wasn't really in the stored procedure.
Especially since that particular stored procedure does not generalize
easily - you have to change it to use it on another table. Users might make
mistakes of using the procedure on a table without a uniqueness constraint
in the right fields, or the wrong uniqueness constraint (e.g. different
collation from the one they use in a select).
Whereas if they had a REPLACE/PUT/MERGE with similar syntax as an UPDATE,
that is less likely to increase the possibility of errors.
Regards,
Link.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannes Dorbath | 2005-11-03 10:55:51 | Re: SQL injection |
| Previous Message | Michael Fuhr | 2005-11-03 09:09:50 | Re: Problem with array in plpgsql function .. please help :-) |