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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] how to deal with sparse/to-be populated tables
Дата
Msg-id 1273.949638697@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] how to deal with sparse/to-be populated tables  (Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>)
Ответы RE: [HACKERS] how to deal with sparse/to-be populated tables  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Re: [HACKERS] how to deal with sparse/to-be populated tables  (Alfred Perlstein <bright@wintelcom.net>)
Список pgsql-hackers
Chris Bitmead <chrisb@nimrod.itg.telstra.com.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Another nasty cache problem
Следующее
От: Chris Bitmead
Дата:
Сообщение: Re: [HACKERS] Another nasty cache problem