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

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: [HACKERS] how to deal with sparse/to-be populated tables
Дата
Msg-id 000b01bf6ecc$d7733a60$2801007e@tpf.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] how to deal with sparse/to-be populated tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] how to deal with sparse/to-be populated tables  (Alfred Perlstein <bright@wintelcom.net>)
Список pgsql-hackers
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
> 
> 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 ;-)
> 

Doens't the following TODO imply it ?

* Allow elog() to return error codes, not just messages

Many people have complained about it.
However,it seems not effective without a functionality of statement
level rollback.  AFAIK,Vadim has planed it together with savepoint
functionality.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp


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

Предыдущее
От: Chris Bitmead
Дата:
Сообщение: Re: [HACKERS] Another nasty cache problem
Следующее
От: Alfred Perlstein
Дата:
Сообщение: Re: [HACKERS] how to deal with sparse/to-be populated tables