From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | chris(at)bitmead(dot)com |
Cc: | Alfred Perlstein <bright(at)wintelcom(dot)net>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] how to deal with sparse/to-be populated tables |
Date: | 2000-02-04 04:31:37 |
Message-ID: | 1273.949638697@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> writes:
> Hmm. Doesn't PostgreSQL have a big list of error codes? I don't think
> it does, I've never seen one. There should be a way to get error
> codes without comparing strings. Should this be on the TODO?
It doesn't, there should, and it already is ;-)
In the meantime, looking at the error message string is Alfred's
only option for distinguishing duplicate-record from other errors,
I'm afraid.
A partial answer to his performance concern is to use a rule
(or possibly a trigger) on the database side to reinterpret
"insert into table X" as "either insert or update in table Y,
depending on whether the key is already there". This wouldn't
buy anything in terms of database cycles, but it would avoid two
rounds of client-to-backend communication and query parsing.
I've never done that myself, but perhaps someone else on the
list has a working example.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Bitmead | 2000-02-04 04:39:59 | Re: [HACKERS] Another nasty cache problem |
Previous Message | Tom Lane | 2000-02-04 04:17:03 | Re: [HACKERS] Another nasty cache problem |