Re: [HACKERS] how to deal with sparse/to-be populated tables

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

In response to

Responses

Browse pgsql-hackers by date

  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