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

Поиск
Список
Период
Сортировка
От Alfred Perlstein
Тема Re: [HACKERS] how to deal with sparse/to-be populated tables
Дата
Msg-id 20000203214116.A25520@fw.wintelcom.net
обсуждение исходный текст
Ответ на RE: [HACKERS] how to deal with sparse/to-be populated tables  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Список pgsql-hackers
* Hiroshi Inoue <Inoue@tpf.co.jp> [000203 21:34] wrote:
> > -----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.

It would help, but it wouldn't be avoid the double searches I seem
to need to do to maintain a unique index.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]


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

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